LINUX.ORG.RU
ФорумTalks

Разрешите поныть про карьеру удалёнщика

 , ,


0

8

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

  • Кучу лет продакшена десктопного гуя с БД под винду;
  • Пару лет фронтенда на Vue;
  • Бэк на C/C++ Linux.
  • Кучу всякий мелкой фигни на C и питоне.

Мне подсказывают, что нынче время ATS, твоё CV не пройдёт, но мне очень не хочется скатываться в обман и работу в команде, набранной ATS и через собеседования «нейросетка оценивает ответы нейросетки».

Есть куча вакансий IoT/embedded, но там требуется личное присутствие. Возможно, я в итоге вернусь обратно в Польшу по этому поводу. Есть удалёнка на всякие HFT и Cloud Linux, но там «у вас меньше 10 лет опыта разработки ядра Linux, вы нам не подходите».

Моя светлая мечта — это найти свой продукт и свою команду, чтобы отвечать результатом, а не на тупые вопросы HR-ов. Но, к сожалению, из-за утизма получается у меня это из рук вон плохо — главным образом в плане «найти заказчика, которого заинтересовали бы мои услуги» или «найти пользователей, которые были бы заинтересованы в моем софте».

Последний год сидел ковырял нейросетки, но опять занимаюсь какой-то бестолковой херней вроде «каким образом Batch Normalization влияет на обучаемость CNN» — в итоге пришел к выводу, по которому уже какое-то время назад написали статью:
https://arxiv.org/abs/1811.12231
«Ну и зачем я этой херней занимаюсь?» — спросил я у себя? На что-то фуднаментальное вне исследовательских групп я вряд ли буду претендовать. Нормальные люди либо из Ollama с FAISS лепят говёные боты поддержки/базы знаний, либо оптимизации на TensorRT, Triton, ONNX разворачивают. А я вот, сижу ковыряю баги из трекера llama.cpp от нефиг делать.

Сначала думал писать в раздел работы, но какая ж тут работа? Тут скорее «помогите вернуться в реальный мир». Но, да, я ищу работу... главным образом C/C++, в идеале линукс, рекомендации смены подхода и «взяться за ум» приветствуются.

★★★★
Ответ на: комментарий от Enthusiast

История работы над настоящими проектами продвинет работников и инвесторов гораздо лучше показушно-привирательных служб поиска работы. «Линкедин» и «Хэдхантер» вместе с «Кикстартерами» останутся далеко позади.

Бред. ЛОР остаётся пристанищем адекватности только потому, что коммерчески он никому не нужен. Не нужен был ни 20 лет назад, ни сейчас. Как только на нём появится коммерческая составляющая, то сразу пойдёт наплыв волчар, напёрсточников, пиарщиков, и прочего скама.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

В данном контексте слово «Гугл» я использую как собирательный образ контор из первой лиги.

Ты меня удивляешь. https://habr.com/en/companies/it_sense/articles/978396/

Не понял твой посыл. Новость в том, что программист не пишет код все 8 часов а футболист не играет матчи каждый день?

Умение на время писать обход бинарного дерева довольно слабо корелирует со способностью строить большие системы.

Дело не во времени а в:

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

urxvt ★★★★★
()
Ответ на: комментарий от urxvt

В данном контексте слово «Гугл» я использую как собирательный образ контор из первой лиги.

А я использую слово «гугл» для обозначения понятия «гугл». Все современные ИИ сделал гугл, весь остальной FAAMN в этой области особо не замечен. Даже OpenAI никаких особенных результатов не выдал. Ну может быть Anthropics ближайший конкурент по исследовательским работам.

Не понял твой посыл. Новость в том, что программист не пишет код все 8 часов а футболист не играет матчи каждый день?

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

Дело не во времени а в:

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

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

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Я, оказывется, IT-стендапер

Надо на сцену идти или другим тексты писать. Будет успех, я считаю.

Kogrom
()
Ответ на: комментарий от byko3y

А я использую слово «гугл» для обозначения понятия «гугл». Все современные ИИ сделал гугл, весь остальной FAAMN в этой области особо не замечен. Даже OpenAI никаких особенных результатов не выдал. Ну может быть Anthropics ближайший конкурент по исследовательским работам.

Тем не менее, всякие ФБ и Ко. от него не отстают в плане условий работы и квалификации кадров. А мы говорим именно об этом.

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

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

urxvt ★★★★★
()
Ответ на: комментарий от urxvt

Они прямо говорят что им нужно — им нужны умные люди. Даже если они не знают С++ или Го. Умные люди выучат их за 21 день.

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

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

ugoday ★★★★★
()
Ответ на: комментарий от urxvt

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

как таковые чистые абстракции требует реально квалифицированные кадры для возведении на них сверхнадёжных систем

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

qulinxao3 ★☆
()
Ответ на: комментарий от urxvt

Тем не менее, всякие ФБ и Ко. от него не отстают в плане условий работы и квалификации кадров. А мы говорим именно об этом.

По ЗП и плюшкам — да не отстают. Но, справедливости ради, в Гугле в своё время талантливые кадры сидели деградировали, теряя связь с реальностью, при это приобретая заоблачное ЧСВ. Но, ещё раз, задача была нейтрализовать потенциальных конкурентов, а не раскрыть таланты.

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

Как раз макака, которая выучила молоток, будет применять молоток везде, для неё это не инструмент, а способ жизни. Особенно резко это заметно при переходе между областями знаний, как то иной ЯП или просто прикладная ниша. Один из самых известных примеров — это Git. Люди уже забыли, насколько всратая командная строка у гита, потому что все пользуются либо IDE, либо вебом, либо иными промежуточными клиентами, либо пару сложных команд у них записано в блокнотике. Уже дошло до того, что libgit2 заново реализует все функции гита, потому что ну невозможно этой баше-парашей пользоваться в автоматической режиме.

byko3y ★★★★
() автор топика
Ответ на: комментарий от ugoday

отбор по iQ в обших затратах на найм(а тем более солтаты(sic!) макнамары им штате более череваты убытками и даже людь средняя по палате может им быть в минус на масштабах ) у корпов просто мизерный поэтому наряду с прочими фильтрами этот один из наиболее max roi как ни странно

qulinxao3 ★☆
()
Последнее исправление: qulinxao3 (всего исправлений: 1)
Ответ на: комментарий от ugoday

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

Согласен, в гуглах приходится, как тут любят говорить, пердолиться даже с обычным веб-фреймворком. И пердолиться без СтекОверфлоу и веб-поиска. Но! примерно та же история и в конторах поменьше: на каждом проекте разработчик встречает незнакомые ему фреймворки и сам проект, который ему не знаком и главная сложность работы в том и заключается, чтобы в нем разобраться. Также предметная область зачастую новая.
Потому, в идеале, умные нужны всем, и Гуглу, и Рога&Копыта. Разница лишь в том, что Рога&Копыта не могут позволить себе таких нанять. Вот и все.

могли бы спросить соответствующие будущему стеку технологий вопросы

Найти человека прямо совпадающим с требованиями проекта очень сложно.

urxvt ★★★★★
()
Ответ на: комментарий от byko3y

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

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

Но, ещё раз, задача была нейтрализовать потенциальных конкурентов, а не раскрыть таланты.

Это единичные случаи.

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

А я ситуацию вижу совершенно по-другому, и это хороший пример того, о чём я говорю. Если человек не понимает самого Гита и просто пользуется ИДЕ, то у него постоянно возникают проблемы и он их решает в стиле «удалить проект и сделать checkout с нуля». Такое я часто наблюдал вживую. Ибо ИДЕ, как абстракция, протекает . И от этого никуда не деться.

urxvt ★★★★★
()
Ответ на: комментарий от urxvt

Ну, чтоб вот на 100% соответствовал должности — тут единственный путь, нанять бывшего коллегу обратно. Но в целом, если вы используете стандартные компоненты, то путь простой. Если нагрузка на AWS, то и девопса спрашиваешь про AWS. Если данные хранятся в Postgres, про него DBA и спрашиваешь. И т.д.

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

Ну, чтоб вот на 100% соответствовал должности — тут единственный путь, нанять бывшего коллегу обратно. Но в целом, если вы используете стандартные компоненты, то путь простой. Если нагрузка на AWS, то и девопса спрашиваешь про AWS. Если данные хранятся в Postgres, про него DBA и спрашиваешь. И т.д.

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

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

Я имел ввиду то, что на каждом проекте половина нового: там PostgreSQL а ты работал с MySQL, освоил PostgreSQL — на новом MongoDB, на третей Aerospike. И эта игра никогда не заканчивается. И это без всяких новомодных штук типа Докера, который уже то ли устарел, то ли нет. Я так и не понял.

urxvt ★★★★★
()
Последнее исправление: urxvt (всего исправлений: 1)
Ответ на: комментарий от urxvt

Если вот нужен специалист прям по PostreSQL, сиди и жди спеца по PostgreSQL. Но, в любом случае, если кандидат получит вопрос по нему, он не будет удивлён и может даже чего-то ответит. А вот если к нам придёт товарищ со стороны и я его спрошу: какие особенности SAP CAM позволяют применить его для настройки SAP BTP с помощью SAP IAS, то единственный возможный ответ здесь: „Дядя, ты дурак?“. И ничего не поделаешь, а людей отбирать как-то надо.

ugoday ★★★★★
()
Ответ на: комментарий от urxvt

Думаешь они этого не знают и закрывают вакансию за два дня?

Думаю не знают. Если написать, что у тебя IoC/DI движок собственной разработки, а по вакансии нужен ссаный Spring, то на тебя посмотрят как на гавно и позовут на собеседование «мидла» со вчерашних курсов Яндекс.Практикум, потому что у него есть теги Spring в резюме.

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Ответ на: комментарий от qulinxao3

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

foror ★★★★★
()
Ответ на: комментарий от urxvt

Найти человека прямо совпадающим с требованиями проекта очень сложно.

Абсолютно точно! Обычно нужных людей «выращивают на месте», а не нанимают на стороне. На стороне нанимают, только чтобы «довести до нужного уровня в требуемой области». Прямо совпадающих с требованиями не бывает.

VIT ★★
()
Ответ на: комментарий от ugoday

Ну, чтоб вот на 100% соответствовал должности — тут единственный путь, нанять бывшего коллегу обратно.

Многие проедпочитают не нанимать одного и того же человека повторно. Знаете почему? Здесь очень уместна поговорка «дважды в одну реку войти нельзя». Свято место пусто не бывает. Место ушедшего уже занято. Наняв обратно, вы увеличиваете риск конфликтов. Если нанимают повторно, то гарантированно не на то же самое место, а либо повыше, либо подальше.

VIT ★★
()
Ответ на: комментарий от ugoday

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

На счет потерял или что попало, конечно, шутка.

VIT ★★
()
Ответ на: комментарий от VIT

Многие проедпочитают не нанимать одного и того же человека повторно.

Я, кстати, много раз наблюдал противоположную картину. И ни разу не слышал, чтобы назад не брали. От шараг и до гигантов.

P. S.
Я смотрю, у меня и многих в этой теме результаты наблюдения рынка труда очень сильно отличаются. Может от страны зависит, не знаю. Но я с РФ и РБ компаниями пересекался, и не заметил особо никакой разницы.

urxvt ★★★★★
()
Ответ на: комментарий от urxvt

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

VIT ★★
()
Ответ на: комментарий от urxvt

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

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

Как говорится, лучше с умными потерять в Гугле, чем с дураком найти в типичном стартапе.

Не знаю, о чём речь. Может быть потому, что не работал в «типичном стартапе». Есть дофигища коллективов не слабее гуловых, с той лишь разницей, что у них нет ресурсов гугла (и то иногда есть). Есть отдельные гении в гугле, но средние кодеры из гугла меня ничем не удивляют, лазерами из глаз не стреляют, спанеры на коленке не собирают. Да, односвязанный список они могут обойти — и чо?

Но, ещё раз, задача была нейтрализовать потенциальных конкурентов, а не раскрыть таланты.

Это единичные случаи.

https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_Litigation
По единичным случаям не выплачивают сотни миллионов долларов штрафов. Процессами из статьи в википедии кадровые махинации не ограничиваются, это просто один из примеров.
Глобальный рынок тупо ограниченный, в какой-то момент просто нет смысла пытаться сделать что-то лучше, потому что получается diminishing returns. В таких масштабах злоупотребление монопольным положением работает намного эффективнее, по крайней мере пока за это не наказывают.

Если человек не понимает самого Гита и просто пользуется ИДЕ, то у него постоянно возникают проблемы и он их решает в стиле «удалить проект и сделать checkout с нуля».

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от urxvt

И это без всяких новомодных штук типа Докера, который уже то ли устарел, то ли нет. Я так и не понял.

Да, докеров наклепали уже целую кучу: containerd, CRI-O, podman, runc. А есть ещё веселые шняги для увеселения процесса сборки образов, вроде nixos. Там бесконечно учиться можно.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Есть дофигища коллективов не слабее гуловых, с той лишь разницей, что у них нет ресурсов гугла (и то иногда есть).

У них и нет задач как в Гугле.

Есть отдельные гении в гугле, но средние кодеры из гугла меня ничем не удивляют, лазерами из глаз не стреляют, спанеры на коленке не собирают. Да, односвязанный список они могут обойти — и чо?

И то, что средний кодер не из гугла его обойти не сможет.

https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_Litigation

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

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

А вот тут я не понял, что ты имеешь ввиду. Что они не хотят лучше поиск сделать? Так никто даже такой сделать не может. Ну кроме китайцев и Яндекса.

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

Ну не знаю. Как по мне, то для обычного использования там ничего сложного нет. Конечно, если человек не может освоить обход или разворот списка то и с Гитом будут проблемы. Ещё бы! весь Гит на деревьях и списках устроен.

urxvt ★★★★★
()
Ответ на: комментарий от urxvt

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

Как ни странно, но да, это судьба большинства крупных компаний — больше половины сотрудников можно уволить без ущебра для бизнеса. Илон Маск в своё время доказал это, уволив 3/4 сотрудников. А у Spotify можно увольнять 90% состава, они всё равно ничерта полезного не делают, только разрабатывают внутренние инструменты для разработки внутренних инструментов.

А вот тут я не понял, что ты имеешь ввиду. Что они не хотят лучше поиск сделать? Так никто даже такой сделать не может. Ну кроме китайцев и Яндекса.

От того, что они сделают «лучше» поиск, у них не станет больше рынка. У гугла нынче посредственный поиск, они оптимизируются под массовый контингент и впаривание рекламы — и им не нужно ничего больше. Дошло до того, что старые сайты по точным цитатам найти не может. Яндекс легчайше забрал рускоязычный сегмент у гугла, но типа «не очень-то и хотелось» — экономика внимания в СНГ сильно иная, нежели в США или европе.

Как по мне, то для обычного использования там ничего сложного нет. Конечно, если человек не может освоить обход или разворот списка то и с Гитом будут проблемы. Ещё бы!

Дело в том, что git положил в фундамент неестественные структуры и методы работы с ними. Большинству людей нужны patch queue, им не нужны ветки, индексы, стеши, и прочие tree-ish. То есть, нужен набор правок, который ты примеряешь к разным веточкам. И ветка в репозитории должна значит «релиз», а не «я меняю смысл ветки три раза на день» через ребейз и форс пуш.
В первых версиях Торвальдс вообще писал комиты руками, никаких merge/rebase не существовало. Потому строго технически git — это инструмент для мейнтейнера ядра Linux. То, что потом сову натянули на глобус? Не первый раз это в айтишке произошло.

весь Гит на деревьях и списках устроен.

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

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от byko3y

Как ни странно, но да, это судьба большинства крупных компаний — больше половины сотрудников можно уволить без ущебра для бизнеса. Илон Маск в своё время доказал это, уволив 3/4 сотрудников. А у Spotify можно увольнять 90% состава, они всё равно ничерта полезного не делают, только разрабатывают внутренние инструменты для разработки внутренних инструментов.

Частично согласен. Но, мне кажется, это не совсем то, о чём мы говорим.

Яндекс легчайше забрал рускоязычный сегмент у гугла, но типа «не очень-то и хотелось» — экономика внимания в СНГ сильно иная, нежели в США или европе.

Забрал после 14-го года? Там больше политика и маркетинг роль играют. Не только качество поиска.

Дело в том, что git положил в фундамент неестественные структуры и методы работы с ними. Большинству людей нужны patch queue, им не нужны ветки, индексы, стеши, и прочие tree-ish.

Пацаны, поднимите руки, кому не нужны ветки! :) Мне они нужны. Линусу тоже, раз сделал. Пользователям svn тоже. У меня ощущение, что почти всем нужны. Индекс и stash я тоже активно использую. Но кому не нужно пускай не использует. В чем проблема то?

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

По моему мнению (и как я понял, у Линуса оно такое же), люди просто неверно используют инструмент — rebase в 99.9% не нужон. Но кругом на него надрачивают, что и ведет к --force push.

В первых версиях Торвальдс вообще писал комиты руками, никаких merge/rebase не существовало.

Потому что он его просто не доделал. Он сделал прототип за 2 недели. Ядро (гита), с минимальным функционалом. И ушел делать дальше Ядро (Линукс).

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

Никаких двух копий нет. Ты получаешь новое (под)дерево а не копию.

urxvt ★★★★★
()
Ответ на: комментарий от byko3y

Маск инженерно тюнил целевую функцию

однако есть отличный текст

Благими намерениями государства - Джеймс Скотт

там на многих примерах - самый топ Германское Лесничество 19 века - показано что в кибернетическом гомеостазе «атавизмы» оказываются не просто так «НЕ нужными теломерами»

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

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

qulinxao3 ★☆
()
Последнее исправление: qulinxao3 (всего исправлений: 1)
Ответ на: комментарий от foror

у тебя IoC/DI движок собственной разработки, а по вакансии нужен ссаный Spring, то на тебя посмотрят как на гавно

Ни разу не встречал таких неадыкватов. Даже когда в молодости был свободен от корпоративной чешуи и мог работать с адекватными альтернативами.

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

ya-betmen ★★★★★
()
Ответ на: комментарий от urxvt

Забрал после 14-го года? Там больше политика и маркетинг роль играют. Не только качество поиска.

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

Пацаны, поднимите руки, кому не нужны ветки! :) Мне они нужны. Линусу тоже, раз сделал. Пользователям svn тоже. У меня ощущение, что почти всем нужны. Индекс и stash я тоже активно использую. Но кому не нужно пускай не использует. В чем проблема то?

Можно вспомнить консольных браузерщиков — ты случайно URL меняешь не через window.open("https://linux.org.ru")? Внутреннее представление малорелевантно для пользователя. пользователю нужно наборы правок переносить в разные ветки и сливать, но в гите нет ни настоящих веток, ни patch queue, это тот самый слепленный за две недели инструмент с минимальным сахаром поверх.

По моему мнению (и как я понял, у Линуса оно такое же), люди просто неверно используют инструмент — rebase в 99.9% не нужон. Но кругом на него надрачивают, что и ведет к --force push.

И у меня оно такое же, другое дело, что ветки должны быть веткам, а не чёрт знает чем из однострочных правок каждые 5 минут — в данном случае Линус придерживается ровно той же политики. Другое дело, что работы, подобной работе мейнтейнера ядра линукса, очень мало в реально жизни. 99.9% людей — не мейнтейнеры ядра линукс.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

сори но Я(!=я) гит юзаю чисто для линейной истории изменений (ну и бэкапа автоматом)

qulinxao3 ★☆
()
Последнее исправление: qulinxao3 (всего исправлений: 2)
Ответ на: комментарий от qulinxao3

сори но Я(!=я) гит юзаю чисто для линейной истории изменений (ну и бэкапа автоматом)

Ну у тебя нет задач «слить изменения от тысячи контрибуторов». Совсем другое дело — когда три калеки начинаю строить схему лондонского метров в истории комитов.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

Всё так, я с этим не спорю.

Можно вспомнить консольных браузерщиков — ты случайно URL меняешь не через window.open("https://linux.org.ru")? Внутреннее представление малорелевантно для пользователя. пользователю нужно наборы правок переносить в разные ветки и сливать

Каких пользователей? Секретарш из бухгалтерии? Да, для них это сложно, да.

но в гите нет ни настоящих веток

Ты точно с Гитом знаком и не путаешь его с svn?

ни patch queue

Не знаю что это.

это тот самый слепленный за две недели инструмент с минимальным сахаром поверх.

Строк в 2 недели говорит не об убогости Гита а о таланте Линуса.

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

Что именно ты имеешь ввиду? Ветка это ветка — просто цепочка коммитов.

urxvt ★★★★★
()
Ответ на: комментарий от urxvt

Строк в 2 недели говорит не об убогости Гита а о таланте Линуса.

Раз уш пошли басни про гения торвальдса и «3-way merge за две недели», то давайте вместе вспомним, чем был git тех времён.
Что делал контрибутор:
1. вносил правки редктором;
2. смотрел что отредактировано show-diff (сравнивал индекс с рабочей копией);
3. если понравилось — записывал правки в индекс через update-cache --add file1.c file2.c;
4. создавал дерево через write-tree получая хэш 78C3B819;
5. записывал это дерево в любую точку истории, в том числе прикреплял к несуществующему комиту через

echo "My commit message" | commit-tree 78C3B819 -p [parent-commit-hash]
Эта команда выдавала хэш комита, который потом контрибутор сбрасывал Торвальдсу мол «implemented lock-free performance counter, commit A71E910F4».

Торвальдс скачивал каталог .git/objects через rsync и далее:
1. делал read-tree -m [parent-commit-hash] [torvalds-commit-hash] A71E910F4, вытягивая коммит в индекс;
2. достаёт все простые слияния (файл изменён только в одном дереве) в рабочую копию через checkout-cache -f -a
3. делал show-diff чтобы посмотреть, где файлы модифицированы двумя человеками, то есть, деревья не получилось слить автоматически;
4. разуруливал конфликты руками;
5. далее то же самое update-cache -> write-tree -> commit-tree.

Как я уже когда-то писал, и ещё раз повторюсь: а вы уверены, что Git сильно удобнее rsync+diff+горстка скриптов? В самом начале Git почти этим и был, с важным дополнением — у него была сишная утилита для создания и чтения «дерева», то есть списка файлов с их контрольными суммами. Весь список полность копировался с каждым коммитоми и оптимизация заключалась лишь в том, что вместо полного содержимого всех файлов применялся хэш, то есть дедуплицировались исходные файлы по их хешу, так что если в новом дереве 9999 файлов не изменились и 1 изменился, то git write-tree просто повторял 9999 хешей и добавлял 1 новый хэш новой версии файла.

Никаких дельт, никакого 3-way merge, даже истории толком не было и регулярно граф комитов ломался. Не было никаких веток — если ты хотел работать с новой веткой, то ты делал cp -r linux-working/ linux-stable/ и пилил свой linux-stable в отдельном каталоге.

Торвальдс сделал инструмент для боли, страдания, кучи ручной работы, и высокой производительности — именно так, как привык работать порядочный сишник тех времён. Жаль, что не только лишь все знают эту поучительную историю — почему-то я подавал её изначально как «очевидный пример», но он очевиден только для меня, судя по всему.

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

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 3)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)