Comments 132
Данный вопрос направлен на то, чтобы оценить компетентность собеседующего. Очень часто при использовании старых БД слышу что-то вроде «так сложилось исторически». Такой ответ считаю неуместным. Технический специалист должен понимать минусы/плюсы используемой им БД. Этот вопрос следует задавать только в том случае, если Вы сами неплохо разбираетесь в различных БД и их отличиях.
Я так понимаю, вы всегда можете ответить на данный вопрос, когда начинаете проект? И не каким-нибудь "ну, эту базу данных я знаю, а с другой у нас никто работать не умеет".
Лично мне кажется, что это довольно жесткое требование. Например, убер не очень справился с этим например, а вроде неплохая технологичная компания.
Хотя бы уметь обосновать, что эту БД знают многие разработчики поэтому мы её и взяли в качестве инструмента.
Даже упоминая алгоритмы и их сложности было бы неплохо чтобы разработчик знал чем тот же самый Redis отличается от PostgreSQL.
… переход с pg на mysql выполнялся строчкой в конфиге
… мы за месяц-полтора одним человеком управимся
Это просто вопрос дисциплины архитектуры.
Нет, это либо тривиальные проекты, либо банальная глупость — пользоваться маленьким подмножеством фич конкретной БД.
Стандарт стандартом, но во-первых полнота его поддержки отличается в разных СУБД, а во-вторых разные СУБД добавляют разные возможности для оптимизации различных запросов.
А в вашем случае, вам остаётся небольшое подмножество стандарта, которое поддерживается более-менее одинаково основными игроками рынка СУБД, в итоге вы делаете запросы неоптимально и с кучей ненужных костылей. Для простых проектов, конечно, без разницы, а для нетривиальных — это потеря производительности и удобства разработки на ровном месте.
Например, как можно использовать PostgreSQL, но при этом не использовать jsonb, PostGIS, CTE, полнотекстовый поиск, оконные функции, индексы по функциям и т.д.? Я уж молчу про партиционирование и прочие тонкости работы с большими БД.
jsonb — это во-первых как раз потеря производительности на ровном месте, потому что при размер json больше пары килобайт мне быстрее будет сжимать и обрабатывать json на стороне приложения.
Причём тут сжимать? Это полноценный document-storage без необходимости затаскивать в проект к-н Mongo без крайней необходимости. Плюс с возможностью использовать эти поля в условиях на выборки.
но по-моему сейчас все БД поддерживают gis
Зато не все ORM поддерживают )))
полнотекстовый поиск — отстой в постгресе, с кучей ограничений
Вы показываете низкую квалификацию такими утверждениями. Любое решение имеет свои trade-offs, и полно случаев когда поисковых возможностей PG более чем достаточно, а затаскивать Solr, Sphinx или Elastic в проект — нецелесообразно.
оконные функции — хм, никогда не использовал
Ну, это говорит о том, что Вы и стандарт плохо знаете, потому что они даже там есть, но детали реализации в разных СУБД отличаются. Для чего используются? Много для чего: https://postgrespro.ru/docs/postgresql/10/tutorial-window
90% проектов это обычные реляционные схемы
90% проектов и даже больше — это тупой CRUD, но это ни разу не повод хотеть заниматься такими проектами.
в 20% обычных web приложений.
Что такое "обычное web приложение"? Не хотите поработать над необычным? )))
И поехали. Сначала касательно mongo, elasticsearch и так далее.
У них есть нормальное шардирование и нормальный кластер, у postgres — нет. В случаи возможности взять es я бы лучше es взял.
И аппеляция к тому что "ой, ну это же другая технология" не очень уместны. Что json, что полнотекстовый поиск в postgres тоже идут как другая технология, не очень связанная с привычной реляционкой.
90% проектов и даже больше — это тупой CRUD, но это ни разу не повод хотеть заниматься такими проектами.
Ну, кто-то же их должен делать? И автор коммента как раз написал, что в этих проектах крутые штуки от специфической бд не очень то нужны.
Убивают программисты, ORM же ничего убить не может, это все лишь инструмент, который переводит питон код в SQL.
а sqlalchemy достаточно гибка и ей можно подсказать.
всякая экзотика вроде pony тормозит.
в orm часто другие узкие места получаются, например построение кучи объектов.
переход с pg на mysqlПлохой пример, не надо переходить с Postgres на MySQL. Переходить нужно как раз в обратном направлении (на Постгрес). Я понимаю, что пока что не всегда есть возможность уйти от MySQL (не все приложения/вики/форумы умеют в pg), но имхо нужно думать и двигаться именно в этом направлении.
habr.com/company/devconf/blog/353682
habr.com/company/southbridge/blog/322624
Она между прочим моложе git (на целых 12 дней).
Работая на проектах и с hg и с git, могу сказать что по функционалу они пересекаются на 90%, при этом функционал mercurial в целом шире, но из за того что система непопулярна, сложно найти адекватную поддержку в тулзах (github, gitlab и тп только для git, потому приходиться юзать другие, менее удобные пакеты и сайты) и это большой минус. Ну и второй минус прилагается — программистам сложно переключаться, все привыкли к git, и внедрить hg в другой компании — шансы близки к нулю, при всех очевидных для меня преимуществах.
В общем автор тут не прав, но видимо что то пошло у него не так. А статья хорошая, спасибо!
Однако, немного уточню. У гитхаба есть поддержка не только для git.
— есть svnhub.com для проектов SVN, это официальная поддержка от github;
— есть плагин hghub.com (это редирект) какой-то самодеятельный (но статус его мне неизвестен, не пользовался)
Также у меня сложилось впечатление, что у hg преимущество не только для «пользователя», но и для администратора. Его гораздо быстрее развернуть и проще настроить на сервере и потом осуществлять поддержку. В этом смысле потребность в «специальных ресурсах» ниже, чем в случае с git.
Да, и если уж на то пошло, что и bitbucket'а есть поддержка hg.
Я пользовался hg-git для своих проектов на гитхабе. Необходимость в этом возникла при миграции этих проектов с google code на гитхаб, когда google code закрыли. Работал hg-git хорошо, нареканий нет, но и проекты это были достаточно небольшие. Окончательно перешёл на git когда понял, что он победил, его знают все и его нужно знать всем — а использовать одновременно и то и другое никакого смысла нет. Хотя hg однозначно был проще и удобнее.
Меня тоже напрягает что СОбеседование часто оказывается экзаменом. Можно подумать СОседям они тоже проводят экзамены перед покупкой квартиры.
P.S. Простите, не удержался, только так и прочёл, ну нет такого слова в русском языке и поза соотвествует.
И как? В скольких из сорока компаний все разработчики пишут тесты?
Почти везде. Видимо мне везло. Но многие говорят что есть, а на деле 20 тестов которые гоняются раз в день.
Это круто! Я собеседовался раз пятьдесят и мне всегда говорили что писать тесты разработчикам некогда.
Все же перечень вопросов заточен на некоторый не очень широкий спектр компаний, которые занимаются, скорее всего, привычным вам вещами. Например список тех, кому можно простить отсутствие тестов всего один пункт про стартапы. А как же хардварщики? Или вы знаете как покрыть тестами код для микроконтроллера, который к тому же может иметь внушительные вставки на ассемблере? А ещё есть компании которые вообще никогда ничего не программировали, но тут им резко понадобился человек в новый отлел, который с помощью этих ваших компукхтеров наконец поможет бизнесу встать на рельсы современности. Понятно, что никакого CI, код ревью и прочего аджайла там нет и быть не может, но разве это не круто с нуля сделать классный проект, особенно если за это готовы хорошо платить? Ближайший пример из жизни — компания всю жизнь занималась радиотехникой, проектировали антенны и усилители, а тут пришёл заказчик и говорит — хочу чтоб ваше железо слало мне данные вот в таком то виде, и вот тут ещё сбоку аналитику надо приделать. И делают, нанимают программистов, те работают, софт их работает. А новомодных методик разработки как не было так и нет
22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик». Таково название статьи. Насколько я знаю python не относится к хардварным вещам. Мб за исключением raspberry или orangepi.
Я тоже так думал. Пока не увидел код управления многотонными механизмами написанный Целиком на питоне. И кстати хорошо работает…
В микроконтроллерах там обычный С и asm, но и логики в них около нуля, просто преобразуют байты в вольты и обратно. А вот вся логика на питоне в линуксе под х86. Ту её часть что отвечает за хотелки заказчика, конечно, покрыли тестами, а вот уровнем пониже стоит регулятор скорости (и не только) на том же питоне и как его автоматически тестировать придумать так и не удалось. Тупо потому что у сервера с тестами нет той самой штуки скорость которой надо регулировать. Она есть где то в другой стране, туда разработчики ездят живьём и живьём же вручную все тестируют, благо площадь полигона и перехват управления в ручной режим позволяют ничего при этом не сломать.
Очень даже легко может исполняться. Есть такой прект https://micropython.org — сам использовал на esp8266
UPD. А, да, статья то про python, так что ассемблер не в кассу. Но тем не менее. Не раз видел (и писал) питоний код, который общается с суровым железом и тестами не покрывается почти никак в виду прямой и неэмулируемой зависимости входных данных от выходных
Мне кажется автоматизированно тестировать в наше время можно что угодно. Было бы желание и средства. Ну а сделать с нуля классный проект, особенно если он масштабный, на мой взгляд невозможно, если нет никаких автоматизированных средств контроля качества.
Тут вопрос что считать масштабным. После какой то степени разрастания кодовой базы, версий и самой команды разработчиков — да, становится (почти) невозможно. Особенно если предполагается такая неприятная сущность как сторонний пользователь, которому нужны фронтэнд, куча уровней защиты от дурака и вот это вот все. Но многим задачам и не нужны такие масштабы, есть вполне серьёзные вещи, которые решаются силами команды из 3-4 человек. Из того что сам видел — видеоаналитика для ЦОДД, там реально всю систему пилят три программиста, один из которых ПиЭм и документации делает больше чем кода. Ну и куда им этот CI?
Как ни странно — проблема автобуса остро стоит для компании в примере на пол ветки выше и то в силу некоторых исторических причин, которые возникли, когда вместо разработчика нанимали технологию (где то даже здесь была статья на эту тему), а привычка писать документацию ещё не родилась. У ребят с видеоаналитикой в этом плане все в порядке — насколько мне известно там или типовые решения, которые любой грамотный новый разработчик сможет без труда понять и воспроизвести или же все довольно неплохо описано в документации, которую просто требуют сверху
Тут правильный вопрос был бы, есть ли у разработчиков вообще доступ к логам на продакшене.
А ошибки на этом продакшене кто исправляет тогда?
А как можно исправлять ошибки, если у вас нет информации к логам на проде? На слух от кастомера?
Закупка ПО, написанием обоснования которого занимался в т.ч. и я, ведется уже около полугода. Из-за закупки другого инфраструктурного ПО, пришлось резко сдергивать проекты с одних серверов и перемещать на другие сервера. Внезапно оказалось, что к новым серверам нет сетевых доступов и это вылилось в офигенный квест с безопасниками, сетевиками и еще 5 или 6 отделами, каждому из которых нужно было доказать, что в этом есть необходимость. И да, если где-то ошибешься — начинай весь этот work-flow заново. Один из моих коллег (тоже разработчик), раз в 2 недели по расписанию, пишет слезное письмо в одну иностранную компанию с просьбой предоставить свежие триал-ключи. Потому что закупка идет, идет уже около года, и обязательно когда-нибудь закончится хэппи-эндом, но пока — дайте ключи, пожалуйста.
Так что нет, это нифига не праздный вопрос, особенно, если это крупная компания, в которой может быть километры всяких бюрократических процедур.
Так что возможно это не человек будет лезть везде, а ему, без его на то желания, будут делегировать те или иные задачи, связанные с ресурсами.
Даже если вдруг повезет, и весь ресурсный вопрос будет висеть на руководителе, то вопрос «как быстро» тоже имеет значение. У нас, к примеру, между согласием купить и покупкой может проходить несколько лет, за которые, сами понимаете, часть людей успеет сменить работу.
Насчёт ELK — вопрос возможно неправильно сформирован. Логи хранить — дело нехитрое. Но разобраться в их огромной каше и как-то их систематизировать — это другой вопрос. Поэтому и спрашиваю про технологию ELK
ClickHouse это классно, да. Еще вот grafana labs выкатити loki. Но в целом еще некоторое время назад ELK был фактически стандарт и ничего другого просто не было.
ELK — это обобщённая аббревиатура. И кстати на собеседовании все прекрасно понимают о чём идет речь даже если у них не используется ни она из трёх букв
Есть еще вопрос, который я задаю потенциальным нанимателям после стажировки в одной достаточно крупной софтверной компании.
Используются ли при учете рабочего времени системы журнализации и записи действий разработчика за компьютером? Удивительно было после первого рабочего дня обнаружить в автоматизированном табеле уведомление — "Учтено 6,5 часов. Необходимо доработать 1,5 часа".
habr.com/post/102620
Как обстоят дела с выбиванием ресурсов?
После прочтения ваших вопросов (они все правильные) встал вопрос, это вы проходили собеседование и устраивались на работу, или это вы проводите собеседования и ищите работников.
Что лучше hg, svh и т.п. — это дело традиций в том числе.
Это не только важный момент, но ещё и объективно — самый сложный, потому что очень трудно отринуть весь свой опыт и все свои единственно верные представления об окружающем мире — и попытаться представить, как мыслит и чего, собственно, хочет тот человек, который будет пользоваться плодами твоей работы. А ему, как это ни странно, может быть важно совсем не то, что важно тебе: не экономия миллисекунд, а грамотно написанная документация, которая позволяет не влезать в исходные коды, чтобы понять «как же оно на самом деле работает», не тестирование, покрывающее искусственно смоделированные ситуации, а возможность оперативно решить проблему в случае возникновения ситуации, которая может вообще никак и никогда не моделироваться в искусственной среде.
Нужно понимать, что наличие реальных денег в компании зависит от заказчиков. И от наличия реальных денег в компании атмосфера в коллективе в российских реалиях зависит порой куда больше, нежели от того, предпочитают там hg или git. И хотя понятно, что с заказчиком взаимодействуют не сами разработчики напрямую — всё-таки не стоит забывать, для кого и для каких реальных условий эксплуатации пишется ваше ПО.
хочет тот человек, который будет пользоваться плодами твоей работы.
Дай бог, чтобы это было именно так. Но порой между конечным потребителем и разаботчиком стоит промежуточное звено (интегратор, посредник и т.д. и т.п.). И не факт, что он понимает потребителя, а вот с разработчиком может и найти консенсус.
1) А что конкретно ваш софт пишет в логи? Есть ли в компании какие-то стандарты, не позволяющие разработчикам не логировать ничего или логировать на «отстань от меня, пожалуйста» или логировать только на этапе отладки, а затем просто на уровне макросов удалять все вызовы логера, «чтоб оно у клиента/заказчика быстрее работало и чтоб клиент не видел лишнего!» Насчёт макросов — вопрос не о конкретном ЯП, а просто принципиальном подходе. Есть такие вещи как OpenLDAP, Samba и Zabbix, умеющие логировать всё чуть ли не построчно, а есть — что-то вроде rsyslogd или zebra, которые могут быть весьма загадочны и непредсказуемы
2) Есть ли определённый стандарт подробности обработки исключений? Насколько распространена ситуация, когда исключение «обрабатывается» (снова по принципу «на… отцепись пожалуйста») на 5 уровней выше того места, где оно возникает? Отличаются ли информация, предоставляемая в случае возникновения исключения, для этапа «отладки» и этапа эксплуатации заказчиком в продуктиве. Есть ли понимание того, что заказчику может быть как минимум неприятно и больно видеть стек-трейс с глубиной вложенности в 20 уровней и что неплохо бы предоставлять в таких случаях информацию, полезную заказчику «что в общих чертах произошло и как это можно исправить», а не предполагать, что заказчик во всех абсолютно ситуациях должен бежать к вам, о великий разработчик, даже если недотестированное и вывалившее какую-то невразумительную околесицу приложение нужно здесь и сейчас. Я неоднократно сталкивался с приложениями, которые вываливали гигантский стек-трейс в ответ на что-то вроде «не могу забиндится на порт» или «такого файла не существует». Если честно, в таких случаях у меня абсолютно всегда возникало желание кастрировать тех, кто так пишет софт. Я сам не всегда пишу тесты и не всегда даже пользуюсь системами контроля версий, но зная о том, насколько критичными бывают вменяемые сообщения об ошибках — хотя бы никогда не делаю их криптографическими и понятными только мне как разработчику.
3) Ну и да, я бы обязательно узнал, почему в компании выбрали именно Python при таком обилии качественных и несложных компилируемых языков со статической типизацией. Потому что база данных — это, безусловно, хорошо (особенно когда это не MySQL vs PostgreSQL, а что-то вроде PostgreSQL vs. ClickHouse vs. Tarantool), но если код пишется на интерпретируемом языке с прекрасным во всех отношениях GIL — наверное, для этого есть очень веские основания? Хорошо бы всё-таки при этом главным основанием была не дешевизна и переизбыток на рынке python-девелоперов, что позволяет убегать на совещания, когда очередной умник начинает задавать слишком много вопросов…
P.S. И да, сложность стандартных алгоритмов (на 99% уже имеющих готовую общедоступную реализацию, в т.ч. в виде C++ блобов для Python) — это, конечно, важно, но для оптимизации производительности неплохо бы знать и некоторые internals целевой системы. Поэтому конечно следует поинтересоваться у потенциального работодателя, что он знает, например, о современной структуре виртуальной памяти в Linux. Ну и классический конечно вопрос: если при async-io один из «потоков исполнения» зависнет — как глубокоуважаемый работодатель проконтролирует это и завершит подвисший кусок кода, упорно не желающий никому добровольно-кооперативно передавать управление? Кстати, поспрашивать работодателя о флагах clone, о преимуществах и недостатках разделяемой памяти (shared memory), о стоимости переходов между разными кольцами защиты ОС — тоже совершенно не повредит…
1) А можно пример? Я не представляю себе как можно стандартизировать логгирование и точно разделить, что логгировать надо, а что нет, не сделав при этом кучу излишних действий и не превратив дебаг логи в полноценную отладочную машину.
2) Может со мной что-то не так, но я никогда не испытывал проблем со стектрейсом, он легко читается и подсказивает где что нужно подправить. Segmentation fault в этом плане значительно хуже.
3) Да бы не начинать холивар по поводу языков могу заменить, что все зависит от точки зрения. Я вот не знаю ни одного достаточно популярного компилируемоего языка, который бы меня так же устраивал как python. Жду когда в rust завезут async/await и можно будет снова проходить растбук.
если при async-io один из «потоков исполнения» зависнет — как глубокоуважаемый работодатель проконтролирует это и завершит подвисший кусок кода, упорно не желающий никому добровольно-кооперативно передавать управление?
Мне вот интересно — это был такой выпад в сторону технологии? Просто вопрос звучит так же, как "как глубокоуважаемый работодатель исправит бесконечный цикл запущенный в собранном c++ бинарнике". Я думаю, вы уже знаете ответ.
Может со мной что-то не так, но я никогда не испытывал проблем со стектрейсом
Я думаю, что с Вами всё так. Просто Вы — разработчик. А я — в большинстве случаев пользователь, пусть и довольно сложного софта. Когда я разрабатываю что-то — мне интересны стек-трейсы. Когда я как пользователь вижу стек-трейс на экране вместо вменяемой диагностики проблемы («Отсутствует файл такой-то, процедура установки выполнена некорректно», «Файл такой-то недоступен для записи, проверьте прав доступа», «Не могут создать новый сокет — проверьте лимиты на количество открытых файлов») — у меня это вызывает как минимум раздражение: я не понимаю, почему я должен видеть информацию, которая понятна только разработчику, если приложение мне дали как продуктивное, а не как некий «subject for deeper debugging». Во многих ситуациях я могу сам исправить проблему или даже искусственно создать приложению те условия, в которых оно всё-таки будет работать, даже если в нём и содержится какой-то баг. Мне-то нужно, чтобы оно работало, а не собирало стек-трейсами «полезную информацию для отладки продуктива».
Тем не менее проблема с async-io — вполне решаема, и это даже не высшая математика, как ни странно.
А не расскажите как? Мне казалось, что такое можно поправить только как-то внешне.
Я думаю, что с Вами всё так. Просто Вы — разработчик. А я — в большинстве случаев пользователь, пусть и довольно сложного софта.
Не только, я тут мастер на все руки :) Просто у меня стек трейсы сидят где-то по середине, самое раздрадающее это "что-то пошло не так" или ошибки, которые вроде как обработаны, но которые не имеют никакого отношения к реальной проблеме, например, когда приложение пишет, что не может подключится к порту, а на самом деле ему не хватает прав создать папку, но у него на все ошибки один обработчик.
А не расскажите как? Мне казалось, что такое можно поправить только как-то внешне.Полагаю, примерно как с убийством тредов извне. Но это работает только если поток не завис насмерть, а просто долго выполняет какую-то синхронную операцию.
Я не представляю себе как можно стандартизировать логгирование
Речь не о техническом документе, хотя для того же кода на C бывает полезно делать trace-отладку типа «вошли в функцию такую-то, важный аргумент такой-то равен вот этому значению» и вокруг обработки внешнего ввода хорошо бы расставлять побольше диагностики, потому что это и есть реальный источник львиной доли ошибок в якобы хорошо протестированных приложениях. Речь скорее о некоем «кодексе чести», чётко сформулированных принципах вроде того, что «не коммитим код со сложной/нетривиальной логикой, не вставив человекочитаемые диагностические сообщения для логера».
Речь скорее о некоем «кодексе чести», чётко сформулированных принципах вроде того, что «не коммитим код со сложной/нетривиальной логикой, не вставив человекочитаемые диагностические сообщения для логера».
Может я не прав, но мне кажется, что задать вопросы с более-менее очевидными ответами довольно странно.
Как и с вопрос о базе данных, если вы потребуете какого-то осмысленного ответа, более-менее опытный разработчик обязательно скажет что-то в духе того, что вы написали. Хотя вряд ли у них прямо будет прописанный Code of Conduct с конкретным списоком пунктов кодекса.
Большинство вопросов внутри этих «22 вопросов работодателю» касаются не конкретных технологий, как там вас решается та или иная программная проблема, а организационных вопросов. Как показала реальная практика работы в компаниях, более 50% проблем в компаниях, IT так точно, вызваны именно проблемами административно-управленческого свойства, а не тем, как вы там прибиваете зависший поток или выполняете миграцию из одного sql в другой. Проблемы административного управления это и подбор кадров, и подбор поставщиков, и управление командой разработчиков, и чистота и порядок в офисе, а не только в код и коммитах в git и т.д. и т.п. Если у вас разработчики трудятся как попало спустя рукава, так как никто не следит, то вы можете выполнять любые миграции, хоть из mongo в postgres одной строкой, но успеха ваша компания не добьётся. И наоборот, написать можно хоть на древнем перле, но благодаря грамотному учёту требований конечных пользователей системы и умелому управлению всем процессом разработки система может процветать и упорно не умирать, хотя все хипстерские разрабы будут воротить нос «там же перл внутри».
В общем автор статьи писал об одном, а Вы к нему с вопросами о другом, образно выражаясь, умело воспользовавшись тем, что буквы и слова и у него и у Вас одинаковы.
> целисообразности
Однозначно говорит в пользу проведения собеседований в письменной форме.
Соответственно, вопросы претендентов к собеседующим тоже имеет смысл принимать в письменной форме.
которые до сих пор использует hg, svn и прочие древние системы контроля версии
А вы можете привести нормальное объяснение на счет mercurial? Или это у вас — не знаю, не использовал, значит плохо?
нет разделения на роли, то есть любой желающий может писаться в develop.
отсутствует нормальный stash.
+ поддержка hg, насколько мне известно заканчивается в след году.
нет разделения на роли, то есть любой желающий может писаться в develop.
отсутствует нормальный stash.
Что?
Вы систему версионирования путаете с настройкой конкретного сервера, а не знание системы с отсутствием функционала.
Простите, но с столь некомпетентными заявлениями очень тяжело слушать и серьезно воспринимать рассказ о том как надо вести себя мидлу.
лучше кинуть ссылки и разжевать.
я на двух местах работы сталкивался с проблемой того что нельзя разграничить доступ на конкретную ветку.
вместо stash-а есть shelve.
посмотрите на bitbucked
shelve да, но с настройками.
защита веток —
1) Опять расширения www.mercurial-scm.org/wiki/AclExtension
2) Регулировать процесс иным способом(делать пуш в иную репу с одного хранилища)
Подходы несколько разные, есть свои плюсы и минусы, и там- и там. Я не буду вам пересказывать статьи выложенные на хабре на тему их сравнения и разводить срач на тему чья
Все что делаю не для себя или просто с кем-то — git ибо почти все его используют. Все что делаю для себя — меркуриал, ибо удобней.
Hg — это и есть mercurial
Все что делаю для себя — меркуриал, ибо удобней.Так точно. Я старый
Плюсы, которые мы активно использовали
— Чекаут части пути
— авторизация из коробки (у гита тоже есть gitolite тот же, но это сторонний продукт)
— если много добавляется и удаляется, чекаут существенно меньше чем у того же гита, нет нужды тянуть все изменения
— это больше решение для разработки с закрытым кодом; разработчиков легче разграничивать в правах (можно выдать доступ только на отдельные ветки), при удалении логина у разработчика остаётся только 1 версия а не полное дерево с первого коммита, и при утечке исходников гораздо проще понять кто виновник
— уже на стадии коммита идёт проверка на «свежесть» версии и если она не последняя то сначала нужен мерж
— А ещё он проще того же гита.
Минус пока только 1 могу вспомнить — невозможность работы без доступа к серверу — ни ветку сменить, ни коммиты заслать.
Это всё то что сходу вспомнил.
Я бы ещё задал пару вопросов:
1 пишете ли вы в соответствии с pep8?
2 сколько нужно времени на согласование новой библиотеки в проект.
Чем больше смотрю на подобные посты, тем больше задаюсь вопросом — люди, вам работать/создавать/добиваться, или антураж/печеньки и как минимум одну новую футболку в неделю, и обязательный вид на горы из окна?
Если я на все эти вопросы отвечу как ожидает задающий, то итоговая стоимость часа разработки для конечного клиента такого работодателя будет запредельная.
Будьте проще. И задайте себе вопрос — а как же раньше все это работало? А то дожили, коммит в гитлаб не пушится и все, можно собираться и домой идти, не могу так работать.
Простите. Наболело.
Нашёл идеал и в нём работаю, чего всем желаю)
Ни про какие горы, антуражи и печеньки я не писал в этой статье.
Согласен, час работы стоит дорого при таких условиях но никто не запрещает Вам работать в компании с иностранным финансированием
Ответ ожидаемый, слышал его не раз. В итоге внутренний Российский заказчик остаётся без исполнителей, т.к. в принципе не в состоянии платить такие деньги за разработку. Отрасль перегрета как раз зарубежными деньгами, а разработчики превратились в «дешевую» рабочую силу для зарубежных «дорогих» денег. Как следствие — даже толковые ребята прозибают в больших компаниях, часто занимаясь неинтересными проектами, с которых не уйти на другие, да и другие проекты — обычно ерунда, просто сваливающаяся от очередного «зарубежного финансирования».
Да, есть исключения — компании, которые пилят именно свои продукты и продают из world-wide, но их не так много (и требования к работникам очень серьезные), а у молодого джуна без опыта, который почитает годик хабр на лекциях в универе, создается ощущение — что работать можно и нужно только в больших корпорациях, где все налажено, и там будет прям весело и круто, как показывают в обзорах офисов гугла и прочих яндексов. Дальше они начинают все это искать, а сталкиваются с аутсорсерами, которые просто продают их как… рабов, простите, зарубеж. Дорого продают.
В итоге внутренний Российский заказчик остаётся без исполнителей, т.к. в принципе не в состоянии платить такие деньги за разработку.
Простите, просто хочу уточнить, правильно ли я Вас понял. Вы пытаетесь сказать, что поскольку у "внутреннего Российского заказчика" нет денег, то разработчики должны идти к нему работать на меньшую зарплату и в худших условиях, потому что… что? Из патриотизма? Чтобы избежать участи "раба", причём "рабство" заключается исключительно в том, что он работает на зарубежных заказчиков? Если я Вас понял правильно, то Вам явно не помешает заглянуть в словарик, почитать определение рабства, потом почитать какие законы Россия принимает в последнее время, и немного подумать… в смысле, подумать своей головой, самостоятельно, без подсказок из телевизора.
Как следствие — даже толковые ребята прозибают в больших компаниях, часто занимаясь неинтересными проектами, с которых не уйти на другие, да и другие проекты — обычно ерунда, просто сваливающаяся от очередного «зарубежного финансирования».
И какова же, на Ваш взгляд, причина того, что в зарубежных компаниях количество неинтересных и ерундовых проектов заметно больше, чем в местных компаниях? Кстати, простите что спрашиваю, но как именно Вы подсчитали количество (не) интересных проектов и там и там чтобы сравнить?
И, да, действительно, толковым ребятам совсем невозможно уйти с неинтересных проектов, ведь рынок так перегрет, хорошие программисты совершенно не могут найти хорошую работу и вынуждены держаться за текущее место, даже если занимаются там полной ерундой.
P.S. Кстати, у меня есть для Вас лайфхак: логику хоть и перестали преподавать в школах, но пока ещё не запретили, так что надо ловить момент, и учить её самостоятельно, пока ещё есть такая возможность.
Если в компании есть DevOps-инженер то они не понимают что такое DevOps, как судя по всему и автор этого текста.
— Есть ли у вас DevOps-инженер?
— Спасибо, до свидания.
В текущих реалиях рынка DevOps-инженер это тот чувак, который занимается CI/CD и новомодными практиками в духи контейнеризации, мониторинга приложений и прочего. Я совсем не понимаю, что вас не устраивает.
Это не культ. Просто отдельный хаброписатель не знает матчасть, вот и всё. А незнание матчасти вызывают сомнения в его экспертизе.
Вы же понимаете, для того, что бы упрекнуть в незнании матчасти, нужно, что бы она была. А четкое определения "DevOps" найти довольно сложно, как и в целом определение чему угодно в программировании. Вспомните тоже ООП. У нас тут нет какого-то существенного научного сообщества, которое смогло бы выработать терминологию, как в той же математике.
Поэтому мне кажется довольно странно придиратся к словам, учитывая, что это довольно часто используемое выражение в описании вакансии.
Коллега, добрый день!
Специально для таких дотошных как вы, я оставил определение для термина devops когда писал эту статью. Если вы не согласны с моим видением того чем занимается devops, то вы можете пройти на сайт hh.ru и ознакомиться с требованиями к devops-инженерам.
На эти вопросы дадут ответы не более, чем в одной из двадцати компаний. А вот другая сторона медали… зарплата в тех компаниях, в которых вам ответят на эти вопросы, вам не понравится =)
Митапы – очень важны. Они позволяют узнать кто и чем именно занимается в данный момент времени. Если у Вас проблемы с публичными выступлениями, то это также поспособствует развитию Ваших soft skills.— увидел тут ссылочку на статью с моего сайта, про софт скиллс. Скажите, полезный материал, зацепил?
Вопросы не мальчика, а джуна. 22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик»