Но в русском БДСМ слово «мастер» в смысле «главный» не употребляется (точнее даже не «главный», а «верхний», если использовать правильную БДСМ-терминологию).
Слово «хозяин» — может использоваться, да.
А то что с английского слово master переводится еще и как «хозяин» для русскоязычных БДСМ-щиков по барабану. Возможно, англоязычные БДСМ-щики и используют слово master, но какое это имеет отношение к русскому языку?
Любой программист на проекте сможет в одну-две функции узнать тип стенда (дев-тест-НТ-прод) и далее вызвать какой-нибудь код, когда тип стенда будет равен проду.
Легко проскочит все стенды, единственный момент — могут увидеть на код-ревью.
И да, такой код я лично видел своими глазами, и даже не раз.
И нет, это не было диверсией (хотя один раз были спецэффекты).
Пример, когда не по злому умыслу:
Например, сталкивался, с тем, что тестовый стенд имел не полную БД (а полная БД это сотни гигабайтов, никто на тестовом полную копию продовой БД не держал), поэтому в коде приходилось специально реализовывать обходной манёвр. И однажды этот обходной манёвр забыли убрать…
Если я вписываюсь в разработку потенциально дорогого проекта — я изначально наберу на него сильных и дорогих разрабов. Или вы хотите сказать, что средненький проект вдруг в какой-то день превращается в проект на миллиард? Я такого еще ни разу не встречал, я думаю вы тоже.
Встречали. Только в другой интерпретации.
Типичная ситуация выглядит так: никто заранее не знает — а взлетит ли проект.
И потому брать сразу на него супер-перцев и давать этим супер-перцам кучу времени на разработку — верный способ разориться.
Поэтому типичная разработка выглядит так: сделать MVP подешевле побыстрее, запуститься, проверить как оно. И, скажу вам, потом MVP редко с нуля перепиливают, ведь проект уже запущен, просто наскоро сляпанный MVP допиливают и развивают.
Как это бывает в реальности расскажу:
Ну вот например на сегодня я пытаюсь скоординироваться с коллегой из другой компании. У нас и у них платежные системы.
Стоит задачи чтобы та компания отправляла нам данные о денежных транзакциях.
Казалось бы: деньги же, по сути, пересылаются — куда как серьезная задача? И программист, разработавший даже MVP платежной системы обязательно опытный перец?
Ага, конечно…
Там есть подзадача — электронная подпись транзакции. Она выглядит как «взять исходный запрос и сформировать подпись: хешировать содержмое запроса методом SHA1, результат хеширования зашифровать RSA».
Думаете у него какая то нетривиальная проблема с ключами или т.п.?
Нет.
Результат хэширования SHA1 — это бинарные данные.
То есть шифрованию RSA подвергаются уже бинарные данные.
И вот про эти бинарные данные мы это с ним 2 недели жуём. Я всё ему уже удаленно отладил. Нашел конкретное проблемное место в его коде:
он просто упорно результат хэширования из бинарного вида то в строку переводит, то вообще сериализирует внутренние объекты своего языка программирования — и в таком виде пытается применить RSA над результатом хэширования.
К слову, эта пара SHA1+RSA во многих программных библиотеках вообще одной функцией реализована, настолько это частая операция. Нужно только в библиотеку правильные параметры передать…
Я уж ему и рабочий пример с curl дал, где видно что и откуда и куда. И прямым текстом говорил, что данные должны быть бинарные.
Но для того человека «тип данных» — пустое слово. Ну не понимает он чем бинарные данные отличаются от текстовых или от внутреннего объектного представления.
Судя по этому факту и по прежним факапам их платежной системы — чел явно студент или джун. Но платежная система у них уже несколько месяцев как в проде. И через неё реальные миллионы ходят. И да — это ему разработку той платежной системы и поручили.
Вы можете сказать: ну это они сами виноваты, они еще с этим разработчиком хлебнут горя, но дело в том, что подобные вещи встречаются куда как чаще, чем вам кажется — никто не желает вкладываться в разработку слишком много. И как раз «совершенно правильный» но дико дорогой процесс встречается исчезающе редко, так как иначе фирма просто не сможет предложить достаточно низкие цены на свои товары. Бизнесмены осознанно предпочитают экономить и рисковать.
Хочется надеяться, что хотя бы ПО для самолётов,…, а-а-а-а, нет, уже была статья на Хабре кто в конечном итоге разрабатывал некоторые части ПО для самолётов…
P.S.:
Пусть вас не смущают старые способы хэширования/шифрования SHA1/RSA — сам протокол обмена данными разработан уже очень давно совсем другими разработчиками, чье ПО несколько лет назад доминировало на рынке. Доминация того ПО канула в прошлое, но их протокол и до сих пор является одним из нескольких стандартов обмена платежными данными де-факто. Его используют, наверное, сотни платежных систем, просто так этот протокол не поменять.
Мы как-то экспериментировали, и загружался только один из vCPU.
Тарантул принципиально однопоточный.
Разработчики говорят, что за счет того, что они даже не заморачивались блокировками внутри, то работает быстрее, чем на несколько потоков, мол проверяли.
А, говорят, если нужно задействовать все ядра — просто запускайте несколько Тарантулов. И делайте шардинг или еще как делите между ними данные.
Коммит>тесты и тестовое окружение>релиз/билд менеджер>прод.
Причём после коммита программист уже доступа непосредственно к закомиченному коду не имеет.
Странно, что на хабре подобные вещи приходится объяснять.
Странно, что на Хабре приходится объяснять — это не работает на 100%.
То о чем вы пишете — идеальный, но не реальный мир.
На 100% тесты не проверяют всех ситуаций полностью.
Иначе бы ПО давным-давно было бы идеально отлажено и багов не было бы вообще нигде. Уж такие фирмы как MS или Гугль могут себе позволить проводить полный цикл проверок, как бы.
Но баги есть и у них.
Суровые нравы програмистов.
Когда я был совсем начинающим электриком, я протирал пыль и отключил электроснабжение половины огромного нефтехимического комбината. Это стоило мне 600 рублей премии в ценах 2004 года.
Я вам больше скажу:
В пору моего джунства, переходящего в мид — я раззорил под ноль целую фирму.
Не такой командой, правда, как «DELETE from users;» но все так же — манипуляциями с данными повредил и основную БД и бэкап.
И всё — фирма в десятки раз сдулась в оборотах, считай умерла, ибо без учета жить не смогла.
Так всё гораздо проще — программисты вообще! не имеют доступа к продакшену, всеми изменениями в прод заведует специально обученный человек.
И всё, подобная ситуация просто в принципе исключена.
Да ладно.
Даже не имея доступа к системе я вполне могу написать в недрах своего кода «DELETE FROM users;» и когда мой код выполнится в проде (а когда нибудь он выполнится, ибо цель написания кода — чтобы он когда-нибудь выполнился в проде) наступит жопа.
Так это как раз говорит о том, что виноват не конкретный уволенный человек (хотя он конечно виноват), а те, кто организовал подобную архитектуру, где программист может любую ерунду отправить в продакшен.
Всеохватывающая система на 100% гарантирующая от факапов — лишена смысла по чисто экономическим причинам. Проверки и перепроверки, перепроверки проверок — а кому работать-то?
На практике — если у вас есть такое желание и злой умысел, то с большой вероятностью вы всё равно сможете хакнуть систему «проверок и перепроверок».
Так что нормальные системы, которые финансово рациональны, предполагают, что конечные исполнители хотя бы худо-бедно старается факапов не допускать.
И если исполнители допускают косяки — доля вины в факапе есть и у организатора процесса и у конечных исполнителей. Накажут ли их — это другой вопрос.
Зависит и от компании — какие вопросы они будут задавать и какие ответы давать на мои вопросы — и от меня. Циклические зависимости )
Заставить то вас принять предложение не в ваших интересах они не могут.
Только если вам кушать нечего и нужно срочно зарабатывать, только тогда вы на невыгодное предложение согласитесь. Но то не вина фирмы была бы, что вам кушать нечего.
Стал бы я увольнять человека за ошибку? “Программа делает то, что ты ей написал”. Но мы же разрабы, мы постоянно ошибаемся.
Проблемой является как выявить первопричину:
Случайность
Злоумышлено
Недоквалификация
В первом случае не увольняют.
Во втором — увольняют плюс иск в суд.
В третьем — переводят на другие работы, попроще (но тут вопрос, захочет ли он на другие деньги).
а у кого-то хоть раз продукты 1с заработали без вложений? всёравно придётся тратить деньги на программистов, так пусть лучше это будет какое-то своё решение, чем непонятно что
От того, что бухгалтер почему то лично стесняется поставить нужные галочки, настроив учет налогооблажения под себя, а приглашает для этого программиста (хотя там реально пару галок поставить, вполне доступно не-ИТшнику) — вовсе не следует, что 1С без программиста не заводится.
Легко заводится.
А еще программистами называют эникеев в среде бухгалтеров, так что я бы не ориентировался на том, что там бухгалтера думают, что 1С им настраивают программисты.
Надо будет затестить far2l дома. В виндовсе мне всегда нравился ТоталКомандер, но его не везде можно использовать и иногда приходилось довольствоваться ФАРом.
Чей-то непонятно.
Если вы только собираетесь попробовать far2l, то под Linux вы ФАР еще не гоняли.
Ну а если под Винду то везде, где можно ФАР, то там и Тотал можно тоже.
Но если консольная запущена внутри графической (ну то есть запустили графический far2l, в нем сделали ssh example.com, а там уже запустили консольный far2l), все ограничения отменяются благодаря чудесным собственным расширениям терминала.
Вот бы еще оригинальный FAR из под Windows это умел. Если через SSH, то какая разница какова операционная система у внешнего (первого) FAR…
Знаете, меня вряд ли можно назвать сеньором. У меня всего 3 года опыта разработки и повидал я сравнительно мало.
Э…
Ну за три года не все джуны выростают до полноценных миддлов.
А уж сеньоров с опытом меньше 5 лет не видел (да и те были гениями, типичный сеньор — это ближе к 7-9 годами, причем не всем дано).
Но в русском БДСМ слово «мастер» в смысле «главный» не употребляется (точнее даже не «главный», а «верхний», если использовать правильную БДСМ-терминологию).
Слово «хозяин» — может использоваться, да.
А то что с английского слово master переводится еще и как «хозяин» для русскоязычных БДСМ-щиков по барабану. Возможно, англоязычные БДСМ-щики и используют слово master, но какое это имеет отношение к русскому языку?
Пример, когда не по злому умыслу:
Например, сталкивался, с тем, что тестовый стенд имел не полную БД (а полная БД это сотни гигабайтов, никто на тестовом полную копию продовой БД не держал), поэтому в коде приходилось специально реализовывать обходной манёвр. И однажды этот обходной манёвр забыли убрать…
Встречали. Только в другой интерпретации.
Типичная ситуация выглядит так: никто заранее не знает — а взлетит ли проект.
И потому брать сразу на него супер-перцев и давать этим супер-перцам кучу времени на разработку — верный способ разориться.
Поэтому типичная разработка выглядит так: сделать MVP подешевле побыстрее, запуститься, проверить как оно. И, скажу вам, потом MVP редко с нуля перепиливают, ведь проект уже запущен, просто наскоро сляпанный MVP допиливают и развивают.
Как это бывает в реальности расскажу:
Ну вот например на сегодня я пытаюсь скоординироваться с коллегой из другой компании. У нас и у них платежные системы.
Стоит задачи чтобы та компания отправляла нам данные о денежных транзакциях.
Казалось бы: деньги же, по сути, пересылаются — куда как серьезная задача? И программист, разработавший даже MVP платежной системы обязательно опытный перец?
Ага, конечно…
Там есть подзадача — электронная подпись транзакции. Она выглядит как «взять исходный запрос и сформировать подпись: хешировать содержмое запроса методом SHA1, результат хеширования зашифровать RSA».
Думаете у него какая то нетривиальная проблема с ключами или т.п.?
Нет.
Результат хэширования SHA1 — это бинарные данные.
То есть шифрованию RSA подвергаются уже бинарные данные.
И вот про эти бинарные данные мы это с ним 2 недели жуём. Я всё ему уже удаленно отладил. Нашел конкретное проблемное место в его коде:
он просто упорно результат хэширования из бинарного вида то в строку переводит, то вообще сериализирует внутренние объекты своего языка программирования — и в таком виде пытается применить RSA над результатом хэширования.
К слову, эта пара SHA1+RSA во многих программных библиотеках вообще одной функцией реализована, настолько это частая операция. Нужно только в библиотеку правильные параметры передать…
Я уж ему и рабочий пример с curl дал, где видно что и откуда и куда. И прямым текстом говорил, что данные должны быть бинарные.
Но для того человека «тип данных» — пустое слово. Ну не понимает он чем бинарные данные отличаются от текстовых или от внутреннего объектного представления.
Судя по этому факту и по прежним факапам их платежной системы — чел явно студент или джун. Но платежная система у них уже несколько месяцев как в проде. И через неё реальные миллионы ходят. И да — это ему разработку той платежной системы и поручили.
Вы можете сказать: ну это они сами виноваты, они еще с этим разработчиком хлебнут горя, но дело в том, что подобные вещи встречаются куда как чаще, чем вам кажется — никто не желает вкладываться в разработку слишком много. И как раз «совершенно правильный» но дико дорогой процесс встречается исчезающе редко, так как иначе фирма просто не сможет предложить достаточно низкие цены на свои товары. Бизнесмены осознанно предпочитают экономить и рисковать.
Хочется надеяться, что хотя бы ПО для самолётов,…, а-а-а-а, нет, уже была статья на Хабре кто в конечном итоге разрабатывал некоторые части ПО для самолётов…
P.S.:
Пусть вас не смущают старые способы хэширования/шифрования SHA1/RSA — сам протокол обмена данными разработан уже очень давно совсем другими разработчиками, чье ПО несколько лет назад доминировало на рынке. Доминация того ПО канула в прошлое, но их протокол и до сих пор является одним из нескольких стандартов обмена платежными данными де-факто. Его используют, наверное, сотни платежных систем, просто так этот протокол не поменять.
Тарантул принципиально однопоточный.
Разработчики говорят, что за счет того, что они даже не заморачивались блокировками внутри, то работает быстрее, чем на несколько потоков, мол проверяли.
А, говорят, если нужно задействовать все ядра — просто запускайте несколько Тарантулов. И делайте шардинг или еще как делите между ними данные.
Ну так это же не одна строка… Реальное ПО намного неоднозначнее.
В реальности эффект «delete from users;» дает какое-то косвенное изменение кода.
Это невозможно на 100%.
Но это «невозможно» не значит, что не нужно стараться сделать систему лучше.
Странно, что на Хабре приходится объяснять — это не работает на 100%.
То о чем вы пишете — идеальный, но не реальный мир.
На 100% тесты не проверяют всех ситуаций полностью.
Иначе бы ПО давным-давно было бы идеально отлажено и багов не было бы вообще нигде. Уж такие фирмы как MS или Гугль могут себе позволить проводить полный цикл проверок, как бы.
Но баги есть и у них.
Я вам больше скажу:
В пору моего джунства, переходящего в мид — я раззорил под ноль целую фирму.
Не такой командой, правда, как «DELETE from users;» но все так же — манипуляциями с данными повредил и основную БД и бэкап.
И всё — фирма в десятки раз сдулась в оборотах, считай умерла, ибо без учета жить не смогла.
Да ладно.
Даже не имея доступа к системе я вполне могу написать в недрах своего кода «DELETE FROM users;» и когда мой код выполнится в проде (а когда нибудь он выполнится, ибо цель написания кода — чтобы он когда-нибудь выполнился в проде) наступит жопа.
Всеохватывающая система на 100% гарантирующая от факапов — лишена смысла по чисто экономическим причинам. Проверки и перепроверки, перепроверки проверок — а кому работать-то?
На практике — если у вас есть такое желание и злой умысел, то с большой вероятностью вы всё равно сможете хакнуть систему «проверок и перепроверок».
Так что нормальные системы, которые финансово рациональны, предполагают, что конечные исполнители хотя бы худо-бедно старается факапов не допускать.
И если исполнители допускают косяки — доля вины в факапе есть и у организатора процесса и у конечных исполнителей. Накажут ли их — это другой вопрос.
Заставить то вас принять предложение не в ваших интересах они не могут.
Только если вам кушать нечего и нужно срочно зарабатывать, только тогда вы на невыгодное предложение согласитесь. Но то не вина фирмы была бы, что вам кушать нечего.
Проблемой является как выявить первопричину:
Случайность
Злоумышлено
Недоквалификация
В первом случае не увольняют.
Во втором — увольняют плюс иск в суд.
В третьем — переводят на другие работы, попроще (но тут вопрос, захочет ли он на другие деньги).
Даже если это слово и где то было в обучающих данных, то встречалось исчезающе мало.
Или модель сама слова способна генерить?
То есть зависит от вас.
От того, что бухгалтер почему то лично стесняется поставить нужные галочки, настроив учет налогооблажения под себя, а приглашает для этого программиста (хотя там реально пару галок поставить, вполне доступно не-ИТшнику) — вовсе не следует, что 1С без программиста не заводится.
Легко заводится.
А еще программистами называют эникеев в среде бухгалтеров, так что я бы не ориентировался на том, что там бухгалтера думают, что 1С им настраивают программисты.
А вы FAR лицензировали с указанием «xUSSR регистрация»?
Чей-то непонятно.
Если вы только собираетесь попробовать far2l, то под Linux вы ФАР еще не гоняли.
Ну а если под Винду то везде, где можно ФАР, то там и Тотал можно тоже.
Вот бы еще оригинальный FAR из под Windows это умел. Если через SSH, то какая разница какова операционная система у внешнего (первого) FAR…
Э…
Ну за три года не все джуны выростают до полноценных миддлов.
А уж сеньоров с опытом меньше 5 лет не видел (да и те были гениями, типичный сеньор — это ближе к 7-9 годами, причем не всем дано).
Сумма вашей зарплаты зависит не от задаваемых вопросов.
А от того примите ли вы предложение с суммой Х или пойдете искать лучшие варианты.
Отмечу, что «тараканы» автора сосредоточены в области проверки самостоятельности мышления кандидата.
То есть он не проверяет глупости типа «реализуете ли вы без интернета сортировку 101 методом».