изучение баш и гит в качестве тестового задания

Есть такая байка, не знаю, насколько правдивая. Где-то на загнивающем Западе налоговая докопалась до шахматного клуба, что те не спортивная организация (которым положены льготы), а коммерческая (которым льготы не положены), потому что клуб брал плату за аренду инвентаря. Судья же не стала выносить решение, а предложила налоговой и шахматному клубу провести матч на 10 досках, чтобы определить, какая сторона компетентнее в вопросе определения природы шахмат — спорт это или нет. Налоговая на этом моменте тихо слилась.

Время испытательного срока три месяца? Я бы нашел на ютубе видосики о гите и баше, или курсы на всяких интуитах и проч. А потом надо челу просто создать репу на каком-нибудь битбакете, и чтобы он создал какой-то скрипт,который м.б. вам и не нужен, но который позволил бы челу ознакомиться с вашей предметной областью.

Человечество не столь быстро деградирует.

В добрых традициях лора:
1. Обучаешь subversion (основные идеи, команды, как работает, что могёт)
2. Простенькая хрень bash + dialog + svn (коммит, log, info, add, remove, merge)
3. Говоришь что svn это какашка мамонта, заставляешь исправить рабочую форму для GIT.
4. Ботаны готовы.

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

если падаван выучит питон, выучит и баш (если вам он действительно нужен).

А питон им нужен? Если нет, нафейхуа его учить? Почему вы все уверены, что питон: 1) простой; 2) в хозяйстве пригодится. Если позиция не девопская и контора не пишет на питоне, то змей не нужен вот совсем. А sh наоборот всегда пригодится.

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

новые версии баша регулярно релизятся

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

Это может быть плохой идеей. Как же у некоторых пердак распинает просто от упоминания тестового задания. Сразу начинаются претензии про «бесплатную работу», «кто мне это будет оплачивать» и т.д. и т.п. Даже если это плёвое задание, которое ни о чём. А за реальную задачу они вообще порвут (или лопнут, что предпочтительнее).

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

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

с почасовой оплатой время отсеивания можно сделать на порядки меньше 3 месяцев

Шахматы - это про способность держать в голове и итерировать 100500 ходов вперёд, умением программировать кореллирует слабо, кмк

ТС ищет программиста, Python востребован больше, чем баш (если не отходить от темы).

Как там Ваши мозги?

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

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

Какой ресурс на эту тему посоветуете?

bash.academy

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

Заодно не будут выглядеть клоунами в глазах будущего сотрудника. Сплошные выгоды.

нужно пилить свою русскую систему контроля версий!

Русскоязычную, разумеется. Предлагаю назвать ее ‘боже’.

Новый репозиторий:

боже мой

Пулл:

боже дай нам почин-12345

Коммит:

боже спаси и сохрани

Пуш:

боже дай им почин-12345

Православно @ благодатно.

Лучше сразу объяснять чем команда занимается, предполагая, что может прийти кто-то быстро осваивающийся и станет во главе разработки. Зачем тут кому-то подкидывать унылые идеи как подыскать не слишком умного человека? Если вы так боитесь конкуренции, то ничего надеюсь у вас не выйдет.

с почасовой оплатой

Это когда не сидел за компьютером === не работал?

новые версии баша регулярно релизятся

Это не делает его нормальным инструментом для скриптинга. https://www.youtube.com/watch?v=jB4vcOjBAmU

Умение играть в шахматы положительно коррелирует с IQ. Умение программировать положительно коррелирует с IQ. Я утверждаю только это.

А кроме того,

держать в голове и итерировать 100500 ходов вперёд

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

Это мода такая гнать на bash, они думают, что так умными выглядят. Базовые знания о конвеере, кодах возврата, переменных и всяких &&, ||, & лишними не будут. Но сильно в дебри уходить смысла не вижу, если не нужно писать скрипты регулярно.

Про это и писалось тут. Разумеется база нужна. Но когда сложность скрипта доходит до условных операторов, циклов и массивов, то тут баш - это действительно набор случайных синтаксических элементов и в таком случае лучше взять тот же питон. А еще для фанатов c++ видел прикольный проект Баш, питон... А исполняемые C++ сорцы с шебангом видали? :).

1. тс не указал какой у них главный яп.
2. да, питон простой и пригодится. Давай сравни в скольких универах питон является 1м яп для обучения а в скольких bash (это про простоту). а теперь приведи пример в какой сфере в мире пригодится шелл? мож бек для веба? ой, не знаю. но для питона есть джанга. мож исчесления? чет не слышал а что в зеленых: есть numpy, scipy. для ML, AI, будет что сказать?
3. шелл как яп не нужен. для написания 5-10 строчников хватит гугления, SO, и охапки старых скриптов для посмотреть. но когда шел-гуру уйдет в другую контору тогда некому будет поддерживать магическое спагетти написанное на одном из диалектов. пора посмотреть в конце-концов как дела обстоят за пределами ЛОРа

шелл как яп не нужен. для написания 5-10 строчников хватит гугления, SO, и охапки старых скриптов для посмотреть

Такой уровень владения и требуется насколько я понял. Чтобы пограмист не впадал в ступор при виде шелл-скрипта, и не бежал писать портянки на C++ или этом вашем питоне там, где можно решить задачу однострочником на баше.

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

мастер читать мысли на расстоянии?

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

Сразу начинаются претензии про «бесплатную работу», «кто мне это будет оплачивать» и т.д. и т.п. Даже если это плёвое задание, которое ни о чём. А за реальную задачу они вообще порвут (или лопнут, что предпочтительнее).

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

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

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

моя идея была в том чтобы не давать абстрактную задачу выучить ЯП ХХХ, а решить задачу (желательно реальный бизнес кейс) посредством ЯП ХХХ

мастер читать мысли на расстоянии?

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

моя идея была в том чтобы не давать абстрактную задачу выучить ЯП ХХХ, а решить задачу (желательно реальный бизнес кейс) посредством ЯП ХХХ

Это да, но это не должна быть нерешённая задача на проекте.

Это может быть плохой идеей. Как же у некоторых пердак распинает просто от упоминания тестового задания. Сразу начинаются претензии про «бесплатную работу», «кто мне это будет оплачивать» и т.д. и т.п. Даже если это плёвое задание, которое ни о чём. А за реальную задачу они вообще порвут (или лопнут, что предпочтительнее).

А я не против задач, может быть если бы у меня было несколько классных открытых проектов и я имел какую-то известность в узких кругах, то кидать мне тестовое задание было бы как издевка. Но у меня ничего нет :) Год назад искал работу, мне явно кинули практическую задачу, нужно было тротлилть запросы к серверу и сделать удобный api. Я сделал за 4-е часа и работу мою приняли, и мое решение вроде понравилось, но было другое предложение, там было только интервью и сразу взяли.

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

мне явно кинули практическую задачу, нужно было тротлилть запросы к серверу и сделать удобный api. Я сделал за 4-е часа и работу мою приняли, и мое решение вроде понравилось

Ну тебе повезло видать. Что каким-то образом тестовое задание как-то совпало с тем что ты примерно недавно делал/узнал как делать и т.д. Да ещё и видать не особо долго думал над архитектурой и как лучше сделать и универсальнее/конфигурабельнее/модульнее и т.д.

Так а сколько вы платить-то будете? И какие у вас задачи?

Автор ищет людей с улицы, которые будут за еду, а еще лучше бесплатно выполнять задания «обучаясь», «получая опыт». Самые ушлые еще и берут деньги «за обучение» — мелькала где-то такая контрора, которая для выполнения 3D моделирования как бы набирала людей на обучение, но реально им давали весла в руки, четкий алгоритм действий, абсолютно бесполезный вне конкретной текущей задачи — и вперед грести.

Как защититься от покупки решения задачи?

Сделать вознаграждение меньше, чем стоимость покупки. Ты думаешь почему оракл, IBM, и даже боинг аутсорсит индусам программирование? Потому что купить решение у индуса дешевле, чем нанимать местного программиста для решения задачи. Причем, может оказаться, что те люди, которым ты аутсорсишь, на самом деле аутсорсят реализацию еще более дешевым индусам, а разницу кладут себе в карман.

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

Замечательно. Берете таксистов и разносчиков пиццы?

Ну тебе повезло видать. Что каким-то образом тестовое задание как-то совпало с тем что ты примерно недавно делал/узнал как делать и т.д. Да ещё и видать не особо долго думал над архитектурой и как лучше сделать и универсальнее/конфигурабельнее/модульнее и т.д.

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

Кстати, в присланном задании меня даже попытались тролить, там была такая строчка - «человеку с таким опытом работы не составит труда выполнить данное задание» :)

это не должна быть нерешённая задача

можете обьяснить почему нужно уже решённую давать?

• Чтобы нормально оценить надо иметь представление о правильном решении (и не теоретическое, а практическое). Обычно это требует решения этого задания самостоятельно. Это видно, когда делают ревью на изменения и ревьювер предлагает что-то левое из-за непонимания деталей реализации задачи. Какая уж тут оценка.
• Код всё равно использовать не получится формально, если не договариваться о лицензии или передаче прав.
• Это действительно похоже на бесплатную работу.
• Всем кандидатам надо давать одинаковое задание. Хорошие задания не так чтобы легко придумать, а найти случайно в трекере маловероятно. Не тестировать же людей какой-то рутиной.
• Это может быть невозможно без доступа к коду проекта, что может требовать подписания NDA или вообще RDP доступа.

Не понимаю такой помешанности современной молодёжи на git’е. Я, например, пробовал погуглить «чем svn лучше git» и мне гугл в упор выдавал заказанные статьи «преимущества git» и на том же опеннете и лоре когда выходят новости про SubVersion так сразу начинается «не нужно»

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

У SVN были свои проблемы, которых нет у Perforce и некоторых других названий, которые я уже не вспомню — какие-то из этих проблем уже решены, но время упущено.

Самое веселое — это причина, почему git победил mercurial. Где-то в районе 2008 года был крупный и неплохой хостинг под названием Bitbucket, и был сравнимых размеров и значимости Github. Руководство Bitbucket было твердо намерено использовать только Mercrial, а Github — только Git. То есть, эдакий недо-vendor-lock. Оба сервиса росли, и вот в 2010 году Bitbucket решает продаться Atlassian. Atlassian не нужен сервис сам по себе — им нужна интеграция с имеющимися сервисами, вроде той же Жиры. В этом переходной период сервис начинает работать из рук вон плохо, вплоть до потери доступа к самому базовому функционалу. Часть пользователей сервиса переезжает с битбакета на гитхаб, рост пользовательской базы меркуриала тормозится, а пользовательская база гита удваивается:

https://blogs.eclipse.org/post/ian-skerrett/trends-eclipse-community-survey-2011

Не то чтобы гитхаб в то время отличался какой-то скоростью — он просто хотя бы работал. В результате гитхаб выходит на сетевой эффект раньше битбакета и за короткое время по экспоненте захватывает большую часть рынка, что с исчерпанием рынка переходит в логистическую кривую. Битбакет мог составить конкуренцию гитхабу, оставаясь верным своему кредо (mercurial), если бы организовал какую-то компанию по привлечению пользователей на очень выгодных условиях. Но в Atlassian посидели, подумали, и решили, что проще будет тупо открыть хостинг на Git, конкурируя с гитхабом за тех же пользователей. На этом история Mercurial в Индии закончилась.

Ты чувствуешь уровень принятия решений? Котики, сисечки, друзяшки вконтактике, стукни в асечку, позвони по вайберу, вступай в группу в фейсбуке — вот как происходит принятие решений в IT-индустрии. Серьезные дядьки собираются на совещание, и после бурного обсуждения решают выбрать Git, потому что у него больше сиськи потому что на Github много проектов хостится. На секундочку: проект с распределенной системой контроля версий хостится на сайте. Прикольная шутка, да? Большинство пользователей гитхаба просто не знает, что такое распрделенная система контроля версий — как ты думаешь, они способны оценить более тонкие преимущества и недостатки используемого инструмента?

Никакой корреляции взрыва популярности Git и отсутствия онного у Mercurial с объективным качеством git/mercurial нет, они не менялись никаким радикальным образом за это короткое время, и, более того, интерфейс Git на винде был и остается лютым говнищем — фактически нативного клиента гита для винды не существует до сих пор. А в 2010-2011 году винда все еще отыгрывала ключевую роль на десктопах.

Я, например, пробовал погуглить «чем svn лучше git» и мне гугл в упор выдавал заказанные статьи «преимущества git»

Не знаю почему, но мне гугл выдает:

— Чем SVN лучше Git?
— Ничем"

и статью Скота Чакона, который работает в гитхабе. Ну типа да, почему бы не написать про свой инструмент. Точно так же Торвальдс напишет «чем линукс лучше винды».

SVN пользуются меньше контор, чем git. Дальше и смысла смотреть нет для Зелёного

Кто пользуется SVN — тот лох.

тебе повезло видать. Попалось то с чем знаком

Нет, первый раз такая фигня

я просто хорошо знал фреймворк, почти 10 лет с ним пишу

o_O вот это взаимоисключающие параграфы :-)

Мне вот интересно, тут закидали тапками баш. Поднимите руки, у кого логин-шеллом установлен не баш (и не другой аналогичный *sh)

У меня winlogon.exe.

Свн малопригодно для реальной разработки. Когда два человека сидят в одной комнате, еще можно работать, если больше и не в одной, то начинаются постоянные конфликты и костыли чтобы это обойти, но потом нужны другие костыли чтобы обойти первые костыли и тд. А еще там всякие неприятные вещи, типа если соединение с репозиторием пропало то работа встала - закомитить же нельзя. Надо держать репу недалеко от себя и все возвращается к двум разработчикам в одной комнате, а если разработчиков 30 и они в разных городах, то можешь сразу идти вешаться.
Вобщем если чел топит за свн, то сразу видно, что он им не пользовался, а если пользовался, то на локалхосте. Хотя даже на локалхосте для одного разработчика гит был бы удобнее

Семь лет пользовался SVN — вообще не понимаю, о чем ты пишешь. Удаленно, разрабы сидели в разных странах. А ты сам точно SVN пользовался?

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

Не было такого, можно было увлеченно работать, хоть неделю не коммитеть :) Потом правда приходилось долго резовить конфлиты на большой объем кода. Хотя обычно в команде все знаю кто над чем работает, потому совсем сложных случаев я уже не помню.

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

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

Однако обыгрывать человека в шахматы компутер научили достаточно давно, а вот сочинять программы как-то не очень

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

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

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

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

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

Я еще раз не верю, что ты серьезно работал когда-то с SVN, потому что ты описываешь типичный RVCS-стиль работы, который в SVN просто не нужен, а потому и проблем подобных не возникает. Кто-то комитит вместе со мной — я просто забираю с сервера его правки и комичу свои на сервер. Есть конфликты — решаю.

тебе повезло видать. Попалось то с чем знаком

Манипуляция. Был другой текст:

Ну тебе повезло видать. Что каким-то образом тестовое задание как-то совпало с тем что ты примерно недавно делал/узнал как делать и т.д.

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

Сама задача для меня была новой, а фрейморк это был spring фактически индустриальный стандарт в моей среде. В задаче нужно было предотвратить частые обращения с одних и тех же ip к некоторым rest, я сделал на аспектах фильтр с очень простым использованием. Над любым метода rest api надо было просто добавить аннотацию и фильтр частых обращений работал против этого метода.

Вот тебе такую задачу дадут на твоем любимом фреймворке, много у тебя времени это займет? А это вполне практическая задача.

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

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

ИМХО git, mercurial и svn - суть стандарт ориентированный на конторы(для малой команды оптимальнее mercurial или тот же git) и выбор зависит от привычки, но для себя можно пользоваться fossil - приятная система контроля версий «всё в одном» от автора sqlite3

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

Отсутствие у распределенных СКВ например, частичного клонирования файлов, svn lock, тонкой настройкой прав доступа и т.д

Я недавно провёл тестирование и определил что GIT при запихивание 1 Гб видеофайла зависает почти на минуту + ещё на коммите тоже пол минуты весит и в фоне думает.

При изменение в hex-редакторе пару байт и повторном коммите папка .git раздувает до 2ГБ.

git gc
git gc-aggressive
git prune

не помогаю и зависают минут на 4 ( на каждой команде)

В тоже время svn тот же файл спокойно перевает за 10-15 секунд и при его модификации не раздувается (дифф занимал всего ~400 Кб)

а про git-lfs ты не слышал, да? ну ладно.