Comments 87
Может проверить весь ваш секретный API-ключ в вашем опенсорсном проекте на Github, потому что это самое быстрое и простое решение.
Оригинал:
Checks in all your secret API-key in your open source project on Github, because that was the quickest and simplest solution.
Это переводится как «Может закоммитить все ваши секретные API-ключи на Github».
Спасибо! Поправили, сейчас все ок?
На гитхаб никто ничего не загружает. Закоммитить это именно закоммитить. Если не хотите использовать жаргонизм, напишите «сделать коммит».
<зануда>Ну если уж быть совсем дотошным, то запушить. Коммитят обычно все-таки в свою локальную репу, а потом уже пушат на какой-нибудь ремот</зануда> Хотя
Я согласен, это так. Но в оригинале — check in, что синоним коммита, а не пуша.
Есть красивый и элегантный жаргонизм «залить», не являющийся калькой с английского.
`check in` — синоним именно пуша, а не коммита, потому что в распределенных репозиториях такого действия нет, оно родом из времен, когда svn было самым прогрессивным хранилищем. В svn — `check in` это push@github, commit@github это add@svn.
check-in == ci === commit
По смыслу, как уже указывали, больше подходит пуш, да.
По смыслу, как уже указывали, больше подходит пуш, да.
Повторюсь, что в оригинале все-таки check-in, а не push, и по поводу этого термина все претензии к автору, а не к переводчику и тем более не ко мне.
Давайте я еще раз попробую. В распределенных системах check-in отсутствует. Но термин жив. Ибо еще живы люди, которые помнят svn. Там существовал check-in (и там от был алиасом commit’а, это правда).
Применительно к github — check-in это push. Period. “Make check-in into remote git repository” переводится c английского на консольный язык как “git push”. Period.
Претензий я никаких не высказывал, не минусовал я никогда из принципиальных соображений, я лишь ответил на ваш неверный комментарий.
Применительно к github — check-in это push. Period. “Make check-in into remote git repository” переводится c английского на консольный язык как “git push”. Period.
Претензий я никаких не высказывал, не минусовал я никогда из принципиальных соображений, я лишь ответил на ваш неверный комментарий.
Если уже быть совсем дотошным, то «закоммитить» родилось в среде пользователей cvs и svn. Там commit означает немедленную отправку изменений на сервер. Отсюда и путаница.
Прошел следующие этапы: псевдокодер, спагетти-кодер, сейчас боюсь дойти до «перфекциониста» с элементами «экспериментатора»
Я думаю, все программисты в разные моменты времени и требований — это сочетания перечисленных в статье за исключением 5 и 8. Последние — не программисты.
1, 3, 4 >< Ибо очень быстро пишу базовый код, который потом несколько раз переписываю, доводя до идеала
Действительно, не кажется ли автору статьи, что категории в общем-то не взаимоисключающие? Например, 6 и 4 вполне могут сочетаться. Но в целом, многие категории как-то наталкивают на представления о начинающем программисте.
Соглашусь. Это не сколько категории, а набор личных качеств. Некоторые категории получаются противоположными экстремумами одной шкалы измерения меры. В списке явно каких-то измерений ещё не хватает.
В идеале у разработчика должен быть баланс при начале работы с поставленной задачей, а уже исходя из ситуации динамически смещаться в ту или иную сторону по мере необходимости. Беда когда программист изначально смещён в своём подходе к решению задач, требуя пристального контроля для соблюдения сроков и качества. Это свойственно молодым и неопытным… Ну, или старым и упёртым.
В идеале у разработчика должен быть баланс при начале работы с поставленной задачей, а уже исходя из ситуации динамически смещаться в ту или иную сторону по мере необходимости. Беда когда программист изначально смещён в своём подходе к решению задач, требуя пристального контроля для соблюдения сроков и качества. Это свойственно молодым и неопытным… Ну, или старым и упёртым.
Полноценный агент 007, за что много раз получал по мозгам от Перфекциониста. Но сработались нормально. В начале задачи пытались работать по его правилам, под дедлайн возжи отдавались мне, и почти всегда успевали. Но в начале следующей задачи он матерясь в душе приводил в порядок мой код решения предыдущей задачи.
Псевдокод слишком негативно освещён. Очень часто перелопачивая несколько страниц технических требований по разрабатываемым продуктам (или уже каких-то инженерных документов) требуется сжато и понятно изложить постановку задаче в issue tracker'а. Простая отсылка к документу и даже его обсуждение не всегда даёт желаемый результат и даже негативно сказывается на производительности команды, т.к. все разработчики вынуждены перечитывать весь документ (100-1000+ стр.), обновляющийся по ходу разработки, чтобы полностью понять одно конкретное требование из него.
Псевдокод позволяет более осведомлённому архитектору и менеджеру, видящих проект целиком, описать требуемую логику, которую впоследствии смогут быстро понять другие участники команды, когда будут разбираться в коде двухлетней давности.
Псевдокод позволяет более осведомлённому архитектору и менеджеру, видящих проект целиком, описать требуемую логику, которую впоследствии смогут быстро понять другие участники команды, когда будут разбираться в коде двухлетней давности.
Любит решать проблемы в рабочих средах, так как его локальная копия для разработки никогда не работает.
Не сразу понятно что за рабочие среды такие. А вот в оригинале все понятно:
Likes to fix things in production environments, because her local development copy never works.
Человек любит сразу на продакшн-серваке разработку вести (в частности)!
UFO just landed and posted this here
Перфекционист какой-то слабый — на картинке нужно больше симметрии.
Как вы алфавитный суп уложите в квадратную сетку по алфавиту «более симметрично»?..
В аду для перфекциониста
ни серы нету, ни огня,
и лишь слегка несимметрично
стоят щербатые котлы © anoubis
ни серы нету, ни огня,
и лишь слегка несимметрично
стоят щербатые котлы © anoubis
Перфекционист-экспериментатор. Такое возможно? :)
У меня в проекте есть копипейстер. Фраза «понятия не имеет, что он делает» просто в яблочко! К сожалению, он не проводит дни на StackOverflow. Для любой даже самой простой задачи он задаст пятьдесят вопросов, до тех пор, когда ему не объяснишь даже не как делать, а как это написать. А после этого добьет еще пятьюдесятью вопросами типа «я написал как ты сказал, а у меня вылез этот эксепшн», и копипейст стектрейса…
У меня в проекте есть копипейстер. Фраза «понятия не имеет, что он делает» просто в яблочко! К сожалению, он не проводит дни на StackOverflow. Для любой даже самой простой задачи он задаст пятьдесят вопросов, до тех пор, когда ему не объяснишь даже не как делать, а как это написать. А после этого добьет еще пятьюдесятью вопросами типа «я написал как ты сказал, а у меня вылез этот эксепшн», и копипейст стектрейса…
Зачем вы его держите? По-моему, такому человеку надо объяснить, что либо он начинает делать всё сам (с разумным привлечением помощи в оговоренных моментах), либо вы с ним прощаетесь.
Как минимум, при желании его можно превратить в человека, который будет говорить: я сейчас не знаю, как конкретно буду это делать, поэтому сначала исследую вопрос, и только потом дам оценку сроков. Но если потакать его желаниям дёргать коллег по каждой строчке кода, он будет продолжать так делать до бесконечности. Это путь наименьшего сопротивления.
Кстати, запрещать ему дёргать именно вас по пустякам бесполезно, он будет дёргать кого-то ещё, причём постарается, чтобы вы этого не видели. Посадите его поближе к себе и смотрите, как он работает.
Как минимум, при желании его можно превратить в человека, который будет говорить: я сейчас не знаю, как конкретно буду это делать, поэтому сначала исследую вопрос, и только потом дам оценку сроков. Но если потакать его желаниям дёргать коллег по каждой строчке кода, он будет продолжать так делать до бесконечности. Это путь наименьшего сопротивления.
Кстати, запрещать ему дёргать именно вас по пустякам бесполезно, он будет дёргать кого-то ещё, причём постарается, чтобы вы этого не видели. Посадите его поближе к себе и смотрите, как он работает.
UFO just landed and posted this here
Собственно я его и посадил писать интеграционные тесты, где надо придумать большое количество данных, заполнять формы и сообщения. При всем при том, что вся инфраструктура тестинга разработана, чел не понимает даже какие случаи надо оттестировать. Весь отчет: «я попробовал запустить тест, высылаю тебе лог системы». К сожалению, решение о его присутствии в команде зависит не от меня. Он был приведен, чтобы «набираться опыта», но челу это как бы не нужно.
К счастью, в моих командах таких случаев не было, но со стороны я это наблюдал. Лучшее, что можно сделать — отстранить его от работы вообще, чтобы не мешался под ногами и не отвлекал других. Пусть сидит тихонько в углу, в игрушки играет. Если ему это не понравится (в чём я сомневаюсь) и он побежит жаловаться своему покровителю — объясните ему, что вы можете либо заниматься обучением дундука, не желающего учиться, либо делать свою основную работу.
Слишком много пунктов, достаточно всего трёх:
1. Куятор — выдаёт быстрый результат всегда ужасного качества, тем кто не знает изнанки нравится, тем кто знает изнанку — нет
2. Потерянный хакер — знает технологии, но результат выдаёт исключительно медленно и обычно не очень хорошего качества т.к. не всегда технологии к месту и не всегда понята задача, никому не нравится.
3. Нормальный программист — пишет нормального качества код, тестирует его. Работает не быстро, но хорошо. Разработчикам нравится, желающим результата кажется что он работает медленно, особенно на фоне куятора.
остальное это уже незначительные модификации этих трёх вариантов
1. Куятор — выдаёт быстрый результат всегда ужасного качества, тем кто не знает изнанки нравится, тем кто знает изнанку — нет
2. Потерянный хакер — знает технологии, но результат выдаёт исключительно медленно и обычно не очень хорошего качества т.к. не всегда технологии к месту и не всегда понята задача, никому не нравится.
3. Нормальный программист — пишет нормального качества код, тестирует его. Работает не быстро, но хорошо. Разработчикам нравится, желающим результата кажется что он работает медленно, особенно на фоне куятора.
остальное это уже незначительные модификации этих трёх вариантов
Куятор куятору рознь. Одно дело выдать результат ужасного качества, который ещё и не решает проблему как надо, и который выгоднее было написать сразу хорошо. А другое — в кратчайшие сроки подпереть падающую стену костылём, или слепить новую функцию из говна и говна (даже не используя палки), чтобы как можно быстрее всё заработало так, как надо.
Грамотный куятор востребован и любим в двух случаях: либо когда всё уже горит, либо когда неясно, надо ли оно вообще, или этот кусок проекта покроется пылью через два дня после релиза. Это и есть «агент 007» по классификации поста.
Грамотный куятор востребован и любим в двух случаях: либо когда всё уже горит, либо когда неясно, надо ли оно вообще, или этот кусок проекта покроется пылью через два дня после релиза. Это и есть «агент 007» по классификации поста.
нене, любовь к куятору означает что всё плохо, ничем хорошим его не оправдать, разве что сферический в вакууме случай когда куятор делает прототип, но сразу после того как становится ясно что он нужен его переписывают нормальные программисты
Вы живёте в идеальном мире, где ничего не падает по вине третьих сторон, о DDoS-атаках ваша компания знает из газет, сервера не умирают посреди ночи, а интернет-каналы всегда стабильны? Что ж, могу за вас порадоваться, потому что где-то в вашей компании сидит куятор, который любезно огораживает вас от всего этого, чтобы вы могли спать по ночам и работать по техзаданию.
Если всё уже горит прямо сейчас и каждая минута простоя влетает бизнесу в кругленькую сумму, составление подробного ТЗ, как и написание кода с покрытием тестами и код-ревью, ни до чего хорошего не доведёт.
Ну а про ваш случай… За свою жизнь я понаписал много таких прототипов. Большинство из них продержались сравнительно недолго и были переписаны после прояснения ситуации с требованиями к продукту, но есть и пара исключений, когда прототип попадал настолько в яблочко, что существенных изменений в него вносить не требовалось несколько лет. Но даже в случае одноразовых прототипов, если бы они не был написаны, этих продуктов бы вообще не было, они был бы навечно похоронены на этапе совещаний и согласований.
Хреновый код при равной стабильности и скорости работы отличается от хорошего кода только маленькой стоимостью написания и сравнительно большой стоимостью изменения. Никаких других отличий между ними нет, как бы ни было приятно многим воображать обратное.
Если всё уже горит прямо сейчас и каждая минута простоя влетает бизнесу в кругленькую сумму, составление подробного ТЗ, как и написание кода с покрытием тестами и код-ревью, ни до чего хорошего не доведёт.
Ну а про ваш случай… За свою жизнь я понаписал много таких прототипов. Большинство из них продержались сравнительно недолго и были переписаны после прояснения ситуации с требованиями к продукту, но есть и пара исключений, когда прототип попадал настолько в яблочко, что существенных изменений в него вносить не требовалось несколько лет. Но даже в случае одноразовых прототипов, если бы они не был написаны, этих продуктов бы вообще не было, они был бы навечно похоронены на этапе совещаний и согласований.
Хреновый код при равной стабильности и скорости работы отличается от хорошего кода только маленькой стоимостью написания и сравнительно большой стоимостью изменения. Никаких других отличий между ними нет, как бы ни было приятно многим воображать обратное.
Нене, то что произошло по вине третьих сторон легко исправляется хорошими админами и программистами (мало того, они пишут так что внешний мир редко что-то ломает), куятор для этого не нужен.
Зато куятор порождает код изменять который может практически только он, а без него стоимость будет очень высока.
Зато куятор порождает код изменять который может практически только он, а без него стоимость будет очень высока.
пятый пункт, судя по отпечаткам, даже копипастит двумя руками. Не преставляю, как можно так нажать одной рукой, чтобы остались такие отпечатки, обычно cmd нажимается боком или даже чуть-чуть ногтевой стороной большого пальца. За исключением копипастера у нас есть все типы
А я нажимаю мизинцем. Как-то так и должен остаться отпечаток.
именно cmd? в случае с ctrl и виндовой клавой, да, мизинец удобнее всего. Но на маковой клаве мне даже приходится прикладывать некоторое усилие, чтобы попасть мизинцем в cmd, а указательным в c/v
ctrl, ага.
cmd на маковой, судя по картинке, расположен как alt на виндовой… Можно средним нажимать, а указательным — с и v, тогда получатся такие отпечатки. Но я бы тоже большим нажимал.
cmd на маковой, судя по картинке, расположен как alt на виндовой… Можно средним нажимать, а указательным — с и v, тогда получатся такие отпечатки. Но я бы тоже большим нажимал.
Я alt на обычной клавиатуре в комбинации Alt+V нажимаю безымянным пальцем. Отпечаток будет полный и нажимать удобно. Так что вполне правдоподобно.
При слепом десятипальцевом вводе разумнее нажимать Cmd/Alt большим пальцем. Остальные модификаторы — уже от клавиатуры зависит, слишком большой разброс. Про функциональные клавиши и говорить нечего, там ад и содомия, особенно на ноутбуках.
Полноценный «4. Перфекционист». Обожаю работать с «2. Господином 90%».
К сожалению, часто приходится делать «7. Спагетти-кодер», ненавижу «6. Экспериментатор», но перфекционирую и его при необходимости :)
К сожалению, часто приходится делать «7. Спагетти-кодер», ненавижу «6. Экспериментатор», но перфекционирую и его при необходимости :)
Пока читал, создалось впечатление, что нормальных программистов, как типа, нет :)
Блин, я мутант, в разные периоды моей жизни на разных проектах во мне были качества практически от каждого типа, разве что кроме псевдокодера)) Как с этим теперь жить?
«Всякая классификация хромает» ©
Вообще, не очень удачно разделены группы. Поведение 2, 3, 4, 6, как правило, вызваны одной и той же чертой характера, поэтому почти всегда проявляются одновременно. То же самое можно сказать про пару 5, 7. Только первый и последний пункты стоят особняком.
Увы, скорее вынужден отнести себя к первой группе.
Вообще, не очень удачно разделены группы. Поведение 2, 3, 4, 6, как правило, вызваны одной и той же чертой характера, поэтому почти всегда проявляются одновременно. То же самое можно сказать про пару 5, 7. Только первый и последний пункты стоят особняком.
Увы, скорее вынужден отнести себя к первой группе.
Не согласен. Про себя могу сказать, что во мне больше всего 2 (увы, борюсь с этим всю жизнь), 6 нет вообще, так как люблю изучитьтехнологию до тонкости прежде, чем применять и не люблю новые, незнакомые подходы — всегда воспринимаю их с недоверием. Перфекционизм во мне развит довольно слабо, код переписываю только когда (если) перестаю в нем ориентироваться из-за запутанности.
В начале проекта — 1, если остается время — 3
До некоторых проектов пункт №3 не добрался
До некоторых проектов пункт №3 не добрался
Знаю еще три типа:
9. Мастер-ломастер (в некотором смысле, крайний вариант агента 007). Абсолютно, всегда и безоговорочно считает, что он знает все, является истиной в последней инстанции и что его решение не просто самое, но единственно верное. При этом почти всегда применяет теоретические знания совершенно не к месту, «поперёк», в результате чего его решения обычно ломают систему, например по-памяти или по-времени работы. Никогда не делает выводов из своих ошибок, говоря «это не я неправильно сыграл, это все вы неправильно спели!» Умудряется за короткое время настроить против себя всех адекватных программистов, потому что постоянно открыто и резко говорит, что те делают «всё неправильно!». Обычно недолго остается в компании, но новую находит довольно легко, так как на собеседовании может свободно говорить на абстрактно-программисткие темы, не привязаные к реальным задачам.
10. Недоразумение (крайний вариант копи-пастера). Чел, попавший в программисты по недоразумению. Недоразумением остается и причина, по которой его приняли на фирму (родственник начальника?). Не знает базовых вещей и врядли узнает, потому что его мозги вообще не приспособлены для программирования. На работе искренне мучается каждый день и каждый час. Очень стыдится и боится того, что другие могут понять, что он вообще ничего не знает, но ему невдомек, что все другие давно уже это поняли. Но не уходит, предпочитая стоять «на краю пропасти», потому что хуже увольнения ничего не будет.
11. Страшила мудрый. Это больше к архитекторам или тем, кто делает дизайн системы/модуля. Был лучшим в универе, может бесконечно рассуждать про классовые диаграммы, паттерны, алгоритмы, теоремы и прочее, но слабовато знает, как это все работает на практике. Делает любой дизайн с расчетом на сто лет вперед, с максимальной гибкостью и возможностью адаптировать буквально ко всему. В результате дизайн становится просто неподъемным и рушится под своим собственным весом. Хорошо, если продукт рушится сразу. Плохо, если работает, покряхтывая от напряжения, потому что тогда он успевает наворотить столько, что приходится потом годами вычищать системы от его «гибкостей» и «степеней свободы»,
9. Мастер-ломастер (в некотором смысле, крайний вариант агента 007). Абсолютно, всегда и безоговорочно считает, что он знает все, является истиной в последней инстанции и что его решение не просто самое, но единственно верное. При этом почти всегда применяет теоретические знания совершенно не к месту, «поперёк», в результате чего его решения обычно ломают систему, например по-памяти или по-времени работы. Никогда не делает выводов из своих ошибок, говоря «это не я неправильно сыграл, это все вы неправильно спели!» Умудряется за короткое время настроить против себя всех адекватных программистов, потому что постоянно открыто и резко говорит, что те делают «всё неправильно!». Обычно недолго остается в компании, но новую находит довольно легко, так как на собеседовании может свободно говорить на абстрактно-программисткие темы, не привязаные к реальным задачам.
10. Недоразумение (крайний вариант копи-пастера). Чел, попавший в программисты по недоразумению. Недоразумением остается и причина, по которой его приняли на фирму (родственник начальника?). Не знает базовых вещей и врядли узнает, потому что его мозги вообще не приспособлены для программирования. На работе искренне мучается каждый день и каждый час. Очень стыдится и боится того, что другие могут понять, что он вообще ничего не знает, но ему невдомек, что все другие давно уже это поняли. Но не уходит, предпочитая стоять «на краю пропасти», потому что хуже увольнения ничего не будет.
11. Страшила мудрый. Это больше к архитекторам или тем, кто делает дизайн системы/модуля. Был лучшим в универе, может бесконечно рассуждать про классовые диаграммы, паттерны, алгоритмы, теоремы и прочее, но слабовато знает, как это все работает на практике. Делает любой дизайн с расчетом на сто лет вперед, с максимальной гибкостью и возможностью адаптировать буквально ко всему. В результате дизайн становится просто неподъемным и рушится под своим собственным весом. Хорошо, если продукт рушится сразу. Плохо, если работает, покряхтывая от напряжения, потому что тогда он успевает наворотить столько, что приходится потом годами вычищать системы от его «гибкостей» и «степеней свободы»,
Я господин перфекционист-эксперементатор 90%. Как лечить?
Еще есть «перфекцехуист» — это когда изначально хочешь сделать идеально… но и так сойдет.
Может загрузить все ваши секретные API-ключи в ваш опенсорсный проект на Github, потому что это самое быстрое и простое решение.
Кроме шуток, один мой знакомый однажды так и сделал.
Обернулось взломом проекта :)
Правда, ничего особо серьёзного не было, но этот случай ему припоминается до сих пор.
Я — Мистер 90 процентов в напряженных ситуациях, но внутренний перфекционист никогда не оставляет в покое.
Настоящий мистер 90%. Теперь буду знать с кем мне работать надо :)
Странно. Ни в одну категорию не попал. Видимо, я уже не программист. :-D
аффтар! все отлично! Погляди как все вокруг начали оправдываться -)
Может быть я один такой странный, но первые 7 пунктов про меня.
В разных ситуациях и проектах подходят различные пункты.
В разных ситуациях и проектах подходят различные пункты.
Агент 007, только постоянно форматирую отступы. И очень часто многовато думаю о том, вынести этот кусок кода в лямбду или функцию или оставить, потому что вроде только один раз копипастить придется. Но последнее время вроде всегда выношу.
А вообще список кажется довольно странным. Если последних 6 много, то индустрии наверное должно быть плохо.
А вообще список кажется довольно странным. Если последних 6 много, то индустрии наверное должно быть плохо.
Тоже практикую вынос кусков кода в лямбду или функцию
почему в лямбду в ряде случаев (а не в просто приватную функцию) — когда что этот кусок кода актуален только в контексте данного метода, и отдельная функция только нагружала бы класс объемом кода.
Выносить в любом случае нужно:
1. Вы можете сразу не знать, будет вызываться код в одном месте или нескольких.
2. Удобно и наглядно, когда вызывается некий кусок кода по «имени» — т.е., видно, что мы делаем, а как — см. детали реализации в функции/лямбде.
почему в лямбду в ряде случаев (а не в просто приватную функцию) — когда что этот кусок кода актуален только в контексте данного метода, и отдельная функция только нагружала бы класс объемом кода.
Выносить в любом случае нужно:
1. Вы можете сразу не знать, будет вызываться код в одном месте или нескольких.
2. Удобно и наглядно, когда вызывается некий кусок кода по «имени» — т.е., видно, что мы делаем, а как — см. детали реализации в функции/лямбде.
Тип 9 (или подтип): Переписать все с «нуля». )
По моим наблюдениям, самые популярные подходы в индустрии — 5 и 7, что считаю крайне печальным.
Я бы еще добавила такой тип программиста — как «учитель» или что-то типа того. Такой тип начинает учить других и этому уделяет больше времени, чем программированию :))
Sign up to leave a comment.
Восемь различных типов программистов