Направление роста стека не всегда определяется архитектурой процессора. У PDP-11, например, стек мог расти в любую сторону, а push и pop были макросами. Что касается вызова подпрограмм, у ARM нет инструкций call и ret, есть только регистр связи − условная верхушка стека вызовов.
Основной посыл статьи понятен и даже банален: не используй для хранения данных незаполненную часть стека, потому что она может быть перезаписана в любой момент (в результате обработки прерывания, например). Но вот про «красную зону» я не знал. Хотя, как я понимаю, использование «красной зоны» на практике − довольно грязный хак, даже когда это безопасно.
Для оценки этой роли достаточно попробовать разбить какой-нибудь npm-модуль на несколько модулей поменьше и перестроить свой проект на использование двух новых модулей вместо одного большого.
Такое в Python тоже можно провернуть, используя только `import`, но импортируя сторонние имена через свой промежуточный модуль.
А ещё в Python можно переименовать модуль:
import module as alias
Другое дело, что такие трюки приводят к нечитаемости кода − другой программист не сразу поймёт, с какими именно библиотеками вы работаете. Мне кажется, к PHP это тоже относится.
Искусство нуждается в самоограничении. Хорошие композиторы не жалуются, что нот всего 7. Архитекторы как фигачили всё одинаковыми прямоугольными кирпичами со времён Римской империи, так и до сих пор фигачат. В балете как минимум с XVI века одни и те же характеры и па. Абстракционисты все умели в пропорции и композицию, так же, как до них импрессионисты − в цвета.
Вот и вы, раз уж заговорили о творчестве, сначала научитесь идиомам, стайлгайдам и прочим best practices, а потом начинайте творить.
В той логике, которую вы мне приписываете, тоже есть некое рацио (минус квантор всеобщности). Да, в андроид-разработке больше дилетантов без фундаментальных знаний, чем, скажем, в веб-бэкенде или эмбеде, потому что и рынок более свободный, и порог входа низкий, и бла бла бла. Но я имею в виду совсем другое. Я, кажется, довольно прямо об этом говорю. После того, как одинесник изучит по долгу службы несколько предметных областей (документооборот, бухучёт, кадровый учёт и т. д.), для собственно программирования в его жизни останется совсем немного места. Эта ситуация противоположна ситуации в андроид-разработке, но она тоже нехороша с точки зрения программирования как профессии.
Решение тут может быть только одно: следовать лучшим практикам, освободить 1С-программистов от задач бизнес-анализа, формализовать процессы − в общем, лишить героев их геройского плаща. Но бизнес обычно не хочет этого делать (по причинам и организационного, и психологического плана), поэтому постоянно огребает геройства, как в моём примере.
В данном случае видеть «со стороны» более чем достаточно. Не надо быть курицей, чтобы судить о качестве яиц. Наверняка разработчики были и бизнес-ориентированны, и системно подходили к проблеме, но вот о многопоточности, о синхронизирующих примитивах, или о стресс-тестировании не знали. Что поделаешь, нельзя объять необъятное.
Абсолютно согласен с ОПом. Спасать мир − это у одинесников в крови. Наблюдал это собственными глазами. Прочувсвовал на собственной шкуре, можно даже сказать.
Крупное торгово-производственное предприятие, филиалы по всей России, несколько тысяч сотрудников на постоянной основе только в одном городе. Учёт и бухгалтерия на 1С. Собственный отдел разработки, сформированный из самых трудоспособных и лояльных сотрудников IT-отделов. Курсы, сертификаты, все дела.
Каждые две недели разработчики выкатывают новую конфигурацию, которую требуется в монопольном режиме «накатить» на рабочие сервера филиала. День получки − бесконечные очереди в кассы: 1С постоянно «вылетает» с ошибкой блокировки, сформировать расчётную ведомость получается с 3-4 попытки. Дело близится к авансу − новый релиз конфигурации: согласно чендж-листу, ошибки блокировки пофикшены. Мы, сисадмины и эникеи, проводим очередную бессонную ночь в обновлении конфы. Аванс − снова очереди, нервы, слёзы, ошибки блокировки. Проходят ещё 2 недели, снова обновление с многообещающим чендж-листом, снова ночной «накат». День получки − скандал повторяется.
С полгода наблюдал такой «релизный цикл», пока меня наконец-то не уволили за разгильдяйство. (Хреновый из меня эникей, что тут поделать.) Не знаю, как у них там сейчас дела, вроде грозились на SAP перейти.
Если хотите знать, как одинесники будут спасать мир − вот так вот и будут.
Фиктивная регистрация − это преступление, и ответственность за неё очень серьёзная. И, тем не менее, торговля пропиской по факту очень распространена, и наказывают за неё редко. Потому что это уголовное право: нужны а) потерпевший, б) неопровержимые доказательства вины обвиняемого. В трудовых спорах всё иначе: обе стороны на равных аргументируют свои позиции.
Давайте всё же представим себе соискателя, которому, например, немотивированно отказали в найме после выполненного тестового задания объёмом в неделю. С чем он придёт в суд или в КТС?
Доказать, что, скажем, вакансия была фиктивная, или что его дискриминировали, очень сложно. Фактов на руках у соискателя нет. А как насчёт ст. 70 ТК РФ? Многие признаки трудовых отношений в этой ситуации налицо. Я не юрист, но думаю, что доказать наличие трудовых отношений тут намного проще.
Вам, чтобы опровергнуть мнение andvgal, надо было бы побеседовать с практикующими юристами или поискать судебные решения. Пока что всё, что я вижу, это ваше ничем не подкреплённое толкование закона против такого же толкования andvgal.
И вы оба почему-то считаете, что Минтруд на вашей стороне, но не хочет или не может высказаться более определённо. В то время как Минтруд совершенно однозначно даёт понять, что последнее слово тут за юрисдикционным органом.
Если не подтверждает и не опровергает, то окончательное решение в каждой конкретной ситуации может дать только суд. И так мы возвращаемся к изначальной постановке вопроса, пусть и в не столь категоричной форме. То есть опровержения как такового не состоялось.
Работодатель вправе назначить испытание, но это не значит, что участие в испытании не является трудовыми отношениями.
Более того, далее в ответе сказано, что «условие об испытании работника» может быть по обоюдному согласию внесено в трудовой договор. Поскольку трудовой договор регламентирует трудовые отношения, то логично предположить, что определённые испытания могут считаться трудовыми отношениями.
Я не хотел вас поправлять в том, как называются разные фичи ЯП. Я имел в виду, что не сто́ит ровнять все ЯП под одну гребёнку. Fluent Interface нерелевантен для Python.
pushиpopбыли макросами. Что касается вызова подпрограмм, у ARM нет инструкцийcallиret, есть только регистр связи − условная верхушка стека вызовов.Основной посыл статьи понятен и даже банален: не используй для хранения данных незаполненную часть стека, потому что она может быть перезаписана в любой момент (в результате обработки прерывания, например). Но вот про «красную зону» я не знал. Хотя, как я понимаю, использование «красной зоны» на практике − довольно грязный хак, даже когда это безопасно.
Такое в Python тоже можно провернуть, используя только `import`, но импортируя сторонние имена через свой промежуточный модуль.
А ещё в Python можно переименовать модуль:
Другое дело, что такие трюки приводят к нечитаемости кода − другой программист не сразу поймёт, с какими именно библиотеками вы работаете. Мне кажется, к PHP это тоже относится.
Вот и вы, раз уж заговорили о творчестве, сначала научитесь идиомам, стайлгайдам и прочим best practices, а потом начинайте творить.
Решение тут может быть только одно: следовать лучшим практикам, освободить 1С-программистов от задач бизнес-анализа, формализовать процессы − в общем, лишить героев их геройского плаща. Но бизнес обычно не хочет этого делать (по причинам и организационного, и психологического плана), поэтому постоянно огребает геройства, как в моём примере.
SAP − это сарказм, если что.
Крупное торгово-производственное предприятие, филиалы по всей России, несколько тысяч сотрудников на постоянной основе только в одном городе. Учёт и бухгалтерия на 1С. Собственный отдел разработки, сформированный из самых трудоспособных и лояльных сотрудников IT-отделов. Курсы, сертификаты, все дела.
Каждые две недели разработчики выкатывают новую конфигурацию, которую требуется в монопольном режиме «накатить» на рабочие сервера филиала. День получки − бесконечные очереди в кассы: 1С постоянно «вылетает» с ошибкой блокировки, сформировать расчётную ведомость получается с 3-4 попытки. Дело близится к авансу − новый релиз конфигурации: согласно чендж-листу, ошибки блокировки пофикшены. Мы, сисадмины и эникеи, проводим очередную бессонную ночь в обновлении конфы. Аванс − снова очереди, нервы, слёзы, ошибки блокировки. Проходят ещё 2 недели, снова обновление с многообещающим чендж-листом, снова ночной «накат». День получки − скандал повторяется.
С полгода наблюдал такой «релизный цикл», пока меня наконец-то не уволили за разгильдяйство. (Хреновый из меня эникей, что тут поделать.) Не знаю, как у них там сейчас дела, вроде грозились на SAP перейти.
Если хотите знать, как одинесники будут спасать мир − вот так вот и будут.
А имеет смысл попробовать ускорить достаточно сложный проект? Этот, например?
Давайте всё же представим себе соискателя, которому, например, немотивированно отказали в найме после выполненного тестового задания объёмом в неделю. С чем он придёт в суд или в КТС?
Доказать, что, скажем, вакансия была фиктивная, или что его дискриминировали, очень сложно. Фактов на руках у соискателя нет. А как насчёт ст. 70 ТК РФ? Многие признаки трудовых отношений в этой ситуации налицо. Я не юрист, но думаю, что доказать наличие трудовых отношений тут намного проще.
Вам, чтобы опровергнуть мнение andvgal, надо было бы побеседовать с практикующими юристами или поискать судебные решения. Пока что всё, что я вижу, это ваше ничем не подкреплённое толкование закона против такого же толкования andvgal.
И вы оба почему-то считаете, что Минтруд на вашей стороне, но не хочет или не может высказаться более определённо. В то время как Минтруд совершенно однозначно даёт понять, что последнее слово тут за юрисдикционным органом.
Это ваше предположение. Минтруд его никак не подтверждает.
Более того, далее в ответе сказано, что «условие об испытании работника» может быть по обоюдному согласию внесено в трудовой договор. Поскольку трудовой договор регламентирует трудовые отношения, то логично предположить, что определённые испытания могут считаться трудовыми отношениями.