Удаленка life (ищу истории успеха)

чтобы привлечь таких же смузихлёбок?

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

Мне не надо «оправдывать» нахождение на удалёнке, я, в принципе, не рассматриваю предложения где её нет

И да, мне иногда надоедает всегда работать в одном месте

И да, мне иногда надоедает всегда работать в одном месте

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

пропустила вопрос:

В чём разница между левыми вайфаями и не менее левым опсосом?

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

Нее, идеш в дикое место, где в никого.

Есть же сумки-тележки на колесиках

а тебе 4 года чтоли, что у тебя распорядок дня?

жопочасы - это основополагающая вещь в жизни большинства людей. «вторник тако», «спортивная среда», «пятница секса» – это жизнь 90% людей планеты. Никто не понимает что можно жить как-то по-другому.

Работаю сидя. Пробовал лёжа - неудобно.

А я вот во время рабочих созвонов частенько ложусь.

А я вот во время рабочих созвонов частенько ложусь.

Ты ещё добавь «и засыпаю» :-)

Нет. :) Бывает слушаю в пол-уха в полудрёме – когда уж совсем не про мою душу, но включаюсь если что интересное.

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

Люто плюсую!

Да какие юга… тут в ДС сдохнешь от жары.

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

Когда SLA - 2 часа, приходится и не такое делать.

да, через левые вайфаи я вообще не полезу даже на тестовые серверы, не то, что на прод

Вы по голому http работаете?

Правила приличия нарушают те, кто тычутся в экраны (правда обычно это смартфоны

Ты немного (много) отстал от жизни

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

Бывает «детонирует» какая-нибудь долго накапливающаяся мина, по тупости не обложенная мониторингом или по вине других подрядчиков. Хочешь или нет - за два часа успей починить или скинуть ответственность.

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

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

В ее манямирок такое не помещается.

Именно место

Работа мне нравится, с этим всё гуд

Единственный раз когда надоела, я и сменил работу. Но это вот было 1 раз за последние 10 лет

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

у нас пока только один раз было +45 в тени

У нас до такого экстрима не доходило.

но самое главное, что начали издыхать серверы, роутеры и прочее оборудование

Немного похожее у нас тоже однажды случилось, началось с того что в серверной сдох кондей. История такая, он изначально бытового уровня был и его хватало на те «полтора сервера» которые робили в серверной, но шли годы, стойки стали забиваться юнитовыми серверами, добавляться шкафы... а кондей оставался прежним, ну и... надеюсь вы поняли логичный итог :)
Контора в виде ГУП, денег дофига, но бюрократияяя, за пять секунд поставить новый кондей невозможно... Притаранили напольный, благо в сервачной окно присутствовало. За давностью лет не помню какого уровня были потери, но что-то было, т.к. установку нового согласовали в рекордные сроки и установили хоть и когда жара прошла, но весьма шустро.

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

Не ужели вам так всегда везёт?
Я раз пять на рабочем проде, без проверок ошибки правил, и один раз из абхазии где тогда с интернетом хреново было.
Как не проверяй казусы бывают (железо - софт и люди дурные постоянно случаются).
Проверять на рабочем это дурдом, но бывает лечить на живом дешевле чем откатывать.

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

При этом, я 3 с лишним года кодил за деньги. Да, можно на чём угодно, даже на мелконоуте и где угодно. Но я заметил, что даже собственный код, через полгода уже почти чужой и нужно минут 20-40 сидеть в полной тишине чтобы вникнуть в проект, разложить его в собственной памяти, чтобы начать что-то менять или ускорять или улучшать. Никакое кафе, никакие пальмы вообще не катят. Только полная тишина и никаких, даже малейших раздражителей. Никакой еды. Можно с чаем, и то, им скорее руки греешь, а когда чай простыл наливаешь новый. Под пальмами жил, если чё, фтопку.

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

это не «везение», а аккуратность и diligence (как это будет по-русски? старание, наверное). правка кода - не игра в рулетку, там не нужно везение. там нужно думать, писать код и тестировать. вообще, обычно нельзя что-то выложить на прод без систем CI, QA и прочего. никто не сидит на рабочих серверах под нагрузкой в риалтайме и не правит там файлы. такое даже страшно представить.

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

И CI твой крутит код прямо в точно таком же окружении и с такими же данными как на проде. И удается предусмотреть прямо все сценарии использования вашого приложения в проде, и все варианты входящих данных. Феноменально уникальная команда, что тут сказать. Снимаю шляпу.
Единственный вопрос, а какого плана ты приложения разрабатываешь (я так понимаю, на плюсах)?

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

такое количество людей удивляет наличие нормальных практик в конторе, типа написание тестов, ci/cd, отсутствие спонтанных публикаций на прод и прочая, што я пребываю в легком замешательстве.

в айтишечке исключительно важны систематический подход, перфекционизм и дотошность.

не коров пасёте!

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

а ещё были времена, когда я писала софт для федеральных компаний: Сбер, ФТС. это была коммерческая компания, но они писали софт, в том числе, для таких крупных клиентов. у Сбера тогда своей разработки не было. и там была своя специфика: софт писался на болванки и рассылался во все отделения Сбера. издавали отдельный официальный приказ и софт обновляли везде. а машин дохрена, они все разные, от мелких деревенских отделений до крупных ЦОДов в ДС. если хоть где-то он не будет работать - это катастрофа. потому что это платежи, это обмен данными банков. то же самое с ФТС: если там бы что-то упало, то остановились бы трансграничные перевозки, «зелёные коридоры» и прочее. это было бы крайне нехорошо. поэтому дейстовать приходилось очень осторожно и всё-всё было обмазано юнит-тестами. и всё работало. нет ничего невозможного. просто надо думать головой и всё тестировать.

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

Я вот не удивляюсь. Все это у «нас» есть. Но вот прям жизнь без инцидентов я еще не видел, ни в своих командах, ни в чужих. Ни в стартапах с тремя калеками, ни в ФААНГах. Понятно, в хороших командах это не случается ежедневно или ежемесячно, но бывает. Ну а мелкие «незаметные» ошибки до прода доезжают прям вообще регулярно.

дотошность

И это я даже не говорю о проблемах, возникающих не по вине ошибок коде как таких. Например. Реализовали мы поддержку протокола Foo и все работало годами. Подключили нового клиента, а он, собака, в поле bar иногда вместо числа строку шлет. По Понедельникам исключительно, а тестировали интеграцию с ним во Вторник, когда все работало как часы.

инциденты бывали. например, как-то перед самым новым годом (буквально три дня оставалось) накатили новую версию в Сбере. тогда начальство могло приказать перед праздниками что-то менять, не было мораториев на работы на серверах перед праздниками. и вот в одном ЦОДе софт начал дико глючить и падать. причём только в одном. я не помню даже, в каком городе. но крупный центр обработки данных. меня сгребли в охапку и я стала работать в режиме без обедов и перерывов на сон в поисках проблемы. перерыли всё. оказалось - ошибка в математической библиотеке у мелкософта. тогда ещё я писала софт под маздай. и в этом ЦОДе они зачем-то накатили на сервер IE, а вместе с ним прилетело обновление математической библиотеки VS. и в ней был брутальный баг, она сегфолтилась. я потратила столько времени и нервов, но нашла источник проблемы. откатили осёл, поставили другую библиотеку, всё заработало. и 31-го числа я спокойно ушла на новогодние «каникулы», в полной уверенности, что Сбер работает :)

к проду никакого доступа из сраных вайфаев и прочих помоек нет даже близко

И это очень разумно! Одобряю!

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

одновременно заливается софт на десятки серверов на разных хостингах по всему миру

...

для этого есть специальный централизованный софт и это делается ночью

Ночью у кого?

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

Сбера. издавали отдельный официальный приказ и софт обновляли везде.
а машин дохрена, они все разные, от мелких деревенских отделений до крупных ЦОДов в ДС. если хоть где-то он не будет работать - это катастрофа.

Может такое когда-то и было в сбере, но это уже давно депрекейтнули. «Что-то не работает» это лозунг современного сбера.

ну, для Сбера ещё писал софт один государственный НИИ. я подозреваю, что из этого НИИ и образовался потом Сбертех. но софт там был тем ещё геморроем ещё тогда. и сейчас, насколько я слышала от самих же программистов, которые работают на Сбертех, что там полное УГ с точки зрения качества разработки. это тоже у нас один чел в чайном клубе мне рассказывал про работу в Сбертехе изнутри. судя по его рассказам, мрак там был изрядный. и вряд ли что-то кардинально поменялось. он потом оттуда ушёл, насколько я знаю.

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

В моем случае это было поле в JSON-протоколе. Так а смысл его проверять? Парсер и так упадет, HTTP 400 пользователю вернется — все как нужно. Проблема в том, что в этом случае может прилететь свыше «а-а-а! почините на вчера, мы трафик теряем».

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

««незаметные» ошибки» могут существовать многие годы, проверено жизнью.

И это я даже не говорю о проблемах, возникающих не по вине ошибок коде как таких. Например. Реализовали мы поддержку протокола Foo и все работало годами. Подключили нового клиента, а он, собака, в поле bar иногда вместо числа строку шлет. По Понедельникам исключительно, а тестировали интеграцию с ним во Вторник, когда все работало как часы.

И подобных вариаций можно ещё не одну тысячу найти.

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

Такая ошибка автоматом проверяется JSON-парсером из коробки. Тут вопрос, скорее, в другом. Что считать ошибкой, а что новым функционалом это вопрос философский. И очень часто разработчик и заказчик (начальник) на это имеют разные точки зрения.
Для разработчика запилить поддержку такого случая это новый функционал (сейчас то все работает согласно стандарту), а для заказчика это обычная ошибка — наше приложение не работает с приложением другой компании. Соответственно он и реагирует, и тут уже откат не поможет — все бегут сломя голову пилить поддержку нового костыля.
Это я, собственно, к твоему утверждению, что умной головой и тестами можно предупредить все проблемы на проде.

тыкаешь носом разработчиков этого «другого софта» в стандарт и они переделывают свою софтину. но написание софта для сетей вообще изрядно параноидальное занятие. абсолютно всё может быть зафакаплено. в любом протоколе, на любом уровне. даже самые стандартные TCP/IP. я там всякого насмотрелась, когда боролась с дидосами. поэтому каждое поле, каждый параметр, всё-всё надо тщательно проверять. и всё это логировать. чтобы потом не было непонимания, почему «по понедельникам» происходят сбои. вот логи, вот ошибки. найти проблему будет несложно. обычно делают логирование разного уровня детализации. и когда надо, включают дебажный уровень и смотрят, что там в логах. это значительно упрощает жизнь всем.

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

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

тыкаешь носом разработчиков этого «другого софта» в стандарт и они переделывают свою софтину.

В реальном мире так далеко не всегда работает. Это стороння компания, которая ради тебя ничего менять не будет, у них это 10 лет так работает.

Есть классическая басня, на эту же тему. Мол в какой-то версии Венды починили ошибку (или просто изменили алгорит аллокатора памяти) и игра начала падать (user after free). Для этой популярной игры запилили спец режим, эмулирующий ошибку.

Не знаю, может на уровнях ниже прикладного это и работает, я в типичной Java-прикладухе варюсь. У нас такое сплошь и рядом встречается.

Его реально в тестировщики надо. У парня талант.

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