Первые заказы, как испытание на прочность

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

Но я мальчик, который выжил, у меня получилось! Помимо того, что я спамил по 20 заявок в день, я брался за все заказы. Даже если не знал, как их делать (я почти никогда не знал). Главное получить заказ, а там уже google, stackoverflow, а теперь еще и chatGpt — прорвемся. По другому опыт не получится заработать.

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

ГитМен — этому проекту нужен новый герой

Это история о том, как я чуть не потерял целый день работы 🤡

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

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

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

Собственно говоря, тогда я и понял, что знать git pull & git push недостаточно

​Фиаско, не смог выполнить заказ

В дополнение к посту о первых заказах. Один раз у меня все-таки не получилось выполнить работу. Заказ был сделать что-то в древней CMS Joomla. Я тогда с коллегой сидел несколько дней безвылазно, но для нас это был просто темный лес по сравнению с wp — ничего не получалось сделать.

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

В общем, проблема была решена и дипломатично, я предложил ему компенсацию за беспокойство в размере 10% от стоимости заказа 500р, лол.

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

P.S. по картинке — кто понял, тот понял 🧐

Нормально объяснить можно?

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

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

Короче говоря, решил сделать, курс, где всей этой воды и нудятины не будет, а все важное и полезное простым языком и с живыми примерами — будет 🫡

Дофига уже написал, сейчас сижу, перелопачиваю документацию, курсы и учебники, чтоб все было в лучшем виде.

P.S. Накидайте реакций, если интересно посмотреть на несколько выдержек с курса 🔥

​🔥70 реакций, ребят, вы вообще дикие, выкладываю 🫡

Поймать баг и не умереть — git bisect

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

Спасение — bisect. Чтобы найти баг эта команда использует бинарный поиск — это как когда ты справочник не по странице листаешь, а сразу открываешь посередине, чтоб понять, в какой половине книги ответ.

1. git bisect start — запускаем поиск!
2. git bisect bad — говорим, что текущий коммит "плохой", содержит баг
3. git bisect good <commit hash> — Указываем, какой коммит точно является хорошим.
4. Все, область поиска обозначена. Теперь git bisect перекинет тебя в коммит посередине — между хорошим и плохим. Ручками, или с помощью юнит тестов проверяем, есть в этом коммите искомый баг и говорим результат гиту с помощью git bisect good/bad. Таким образом ты сузил область поиска в 2 раза.
5-inf. Повторять предыдущий шаг, пока область поиска не сузится до одного-единственного коммита.

Кроме того, git bisect залезет даже в смерженные ветки, если окажется, что баг спрятался в них.

P.S. Как же тяжело урезать статью до поста — все время хочется добавить больше полезности и примеров

Ребят, все же в школе/колледже/универе изучали математику, физику и т.д. Расскажите, как по ощущениям, пригодилось в работе?

Так нужен матан-то?

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

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

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

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

На подумать — у меня есть знакомый программист, который не шарит за математику настолько, что я объяснял ему, как работают проценты. Так вот, за 7 лет в it он освоил только одну древнюю CMS.

Вспоминаю сейчас, как я все-таки взял себя в руки и разобрался с гитом

Ощущение было, будто заново ходить научился.

1. Меня перестало бесить переключение между тасками, потому что можно не комментить недописанный код, а просто переключиться на другую ветку.
2. Когда всплывал какой-то древний баг — я перестал логировать каждую строчку в 20 файлах ,пытаясь понять, что пошло не так, а просто ипользовал bisect
3. Начал сам разбираться в своем и чужом коде — коммиты с четким описанием по утвержденной структуре, ветки под таски - все это очень здорово помогает не устроить из кода бардак + по истории легко отследить зачем и кем код был написан.
4. Работа с командой! Для меня было открытием, что если нормально выстроить управление репозиторием — можно спокойно и без путаницы работать даже над большим проектом.

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

P.S. На фото я, когда преисполнился в познании гита

Переработки, как способ ничего не сделать

Берешь больше работы -> не успеваешь -> работаешь больше -> устаешь -> не успеваешь еще больше -> работаешь еще больше.

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

Но вот не получается так. Не работает. Чтобы работать эффективно — у тебя должны быть силы. Чтобы у тебя были силы — ты должен отдыхать.

Мне было очень трудно принять это и пересилить свое "тогда я вообще спать не буду и в туалет не пойду, пока не доделаю". Но сейчас я прямо ощущаю эффективность отдыха. Устал, не варит голова — вышел, покатался на велосипеде, вернулся и доделал за 5 минут.

Главное размяться и вылезти из компа, а не в вк залипнуть на час.

Программисты, которые не пользуются гитом — вы кто?

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

Буквально в этом году на проект пригласили фронтенда: много кейсов в портфолио, более или менее приятный код, да и вообще с человек знаком, пускай и шапочно — знаю, что человек в it несколько лет как минимум. В общем, кажется, все ок. Созваниваемся, показываю тонкости проекта. кидаю ему ссылку на репозиторий, а мне в ответ неуверенное: "а, у вас на гите все... я с ним не сталкивался, мне что-то скачать нужно?"

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

Я понимаю, как можно не помнить флаги reset, понимаю, как можно не знать о Git LFS, но как можно умудриться за несколько лет работы обойти git целиком — не понимаю

​Тру прогеры кодят на линуксе

Так? Так ведь?

Я с линуксом познакомился в период, когда на то чтобы окружить себя атрибутами программиста я тратил сильно больше сил, чем на сам кодинг. Я прочитал, что настоящие жостики сидят на Arch — поэтому 3 дня сидел с туториалами и терминалом, чтобы накатить наконец этот гребаный трушный линукс. Потом я прочитал, что реальные хакеры пользуются Vim, а все IDE для слабаков — слабаков, которые не могут найти выход из Vim. После этого я, конечно, всем подряд доказывал, что это очень удобно и если у тебя стоит винда — ты вообще не программист. Хорошо, что тогда мне не попалась никакая статья о веганстве.

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

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

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

P.S. Ниже архивное фото, 2018год — я жестко гуглю, как войти в терминал в линуксе

​Как назвать коммит, чтоб тебя не побили

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

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

git commit -m "TYPE (subject) short description

Long description."

TYPE

Тип нужен чтобы быстро понять задачу коммита

1. FEATURE - используется при добавлении новой функциональности
2. FIX - если исправили какую-то серьезную багу
3. DOCS - всё, что касается документации
4. STYLE - исправляем опечатки, исправляем форматирование
5. REFACTOR- рефакторинг кода
6. TEST - всё, что связано с тестированием

Subject — это область, в которой была проведена работа, например news или workers. Например, сломались новости — ты ищешь только в коммитах с указанной областью news.

Short description — короткое описание проведенной работы, зачастую его хватает за глаза.

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

Систему можно менять под потрбености конкретного проекта, но в целом так удобно искать коммиты через git log --grep, да и вообще, с одного взгляда на коммит понятно, о чем он и нужен ли он тебе.

Сейчас дописываю статью для курса по автоматическому деплою с GitHub. По ходу получается бомба 🔥

Мне самому в первый раз было очень страшно к этой теме притрагиваться, во всех туториалах, что я читал все кажется безумно сложным и запутанным. А толкового объяснения кода для GitHub Actions я вообще не нашел — мучал chatGpt и знакомых прогеров, чтобы каждая строка была очевидна.

Какие темы лично тебе хочется увидеть в курсе? Если я что-то упустил — обязательно добавлю!

Важно!

Меня сегодня в BitBucket заблочили.

Вот с таким юрлом, что дает инфы больше, чем сама карточка на сайте: https://id.atlassian.com/login/inactive?blockedByReason=Blocked+by+Atlassian+due+to+business+wind+down+within+region&blockedByType=orgAdmin

Заблокирован по причине=Заблокирован+компанией+Atlassian+из-за+прекращения+бизнеса+в пределах+региона&blockedByType=Администратор

Дружно создаем копии репозиториев, у кого доступ еще не прикрыли

UPD: Блокируют не всех, по какому признаку непонятно

​Как влюбить в себя клиента и жить с ним долго и счастливо?

Будь. Человеком.

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

1. Вникни в проект, задай вопросы. Постарайся понять задумку. Будь заинтересованным. Ведь это для тебя проходной проект на несколько дней/месяцев, для клиента — это его детище, стоящее для него на первом месте. Говорю как клиент: если исполнитель реально загорается проектом и вникает в него — я могу забить на многие косяки.

2. Вноси предложения. Здесь нужно быть осторожным и не переборщить, но тем не менее)) Я часто, когда делаю какой-нибудь сайт вижу косяки старого кода, или проблемы в дизайне или крутую возможность — я говорю об этом клиенту и часто он ко мне прислушивается. К тому же это доп. работа = доп. деньги.

3. С пониманием относиться к правкам. Ну опять же, это его детище, для человека важно, чтоб оно было по итогу хорошим. Если это твои косяки — исправь. Если это новые задания — помоги клиенту составить по ним хорошее ТЗ с отдельной оплатой.

4. Быстрые ответы. Даже в 12 ночи. Игнор всегда бесит. Если ты сейчас не можешь ответить — напиши, что ответишь через час/утром. Так клиент останется услышанным, он будет знать, что ты не забил и ответишь ему.

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

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

Курс почти готов. Докручиваю последние винты и в продакшн!

Итак, краткая информация по курсу:

Про что курс: про работу с гитом от базы, типа pull&push до GPG подписей, восстановления файлов и правил хорошего тона. Настоящий набор джентльмена.

В чем фишка:
- Без воды и избыточной информации. Мне самому надоело гулять по документации по полчаса, чтобы найти объяснение нужному мне флагу. Теперь я залезаю в свой же курс.
- Удобная структура. Я построил курс так, что начать юзать гит можно уже после 10 минут чтений курса. Необходимая база — в самом начале.
- Понятная навигация. Понятное дело, что нет смысла зубрить все команды. Когда понадобятся — просто зайдешь в курс и возьмешь оттуда, что нужно. И в отличие от большинства курсов — тут это удобно.

Сколько стоит: 4 000р.

Когда: уже в эту среду. Я открою продажи на 3 дня: с 20.09 по 22.09 включительно.

Зачем этот курс вообще?

Я тут столкнулся с мнением, что курс нужен только тем, кто сейчас собирается учить гит.

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

Ситуация 1. Ты лампово кодишь и заливаешь новую фичу в master. После этого ты сразу видишь ошибку и нужно срочно откатиться, пока никто не заметил. И вот тут вместо того чтобы ставить рекорды по скоростному гуглению — ты просто открываешь статью курса и по инструкции откатываешься.

Ситуация 2. Тебя попросили смержить твою фичу в мастер и потом создать тег — ты опять идешь на курс, в котором вся информация уже подготовлена, а не исследуешь 3 статьи на хабре и 4 вопроса на stackoverflow.

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

P.S. Я собственно говоря, сам своим курсом также пользуюсь. Не буду же я это все помнить

Что с ценой, почему 4 000р? Дорого или дешево?

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

4 000 рублей — это один раз потерянные пол дня работы, что без гита — не вероятность, а судьба.
4 000 рублей — это несколько часов поиска информации по гуглу, документации и stackoverflow.

В конце концов, 4 000 рублей — это десятки часов моей работы, чтобы этот курс сделать.

Не мешай себе работать

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

Когда работа идет легко, кодить не в лом, а наоборот интересно — не прерывай это! Вдохновение — дама капризная, время не выбирает.

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

Не всегда получается жить в балансе со своими желаниями. Конечно, приходится подстраиваться под расписание. Но если есть возможность — не мешай себе и своему организму. Хочется отдохнуть — отдыхай, хочется работать — работай. Хочется третье пирожное за ночь — кушай! А потом страдай в спортзале

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

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

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

Я за честные продажи, которые приносят только пользу ❤️

Стартуем!

Кроме того, по просьбам трудящихся я решил сделать скидку для самых быстрых!

Сегодня, в один из трех дней курс можно купить за 3000р!

Чтобы купить курс — пишите мне в личку: @bubnov_dev

Еще раз, скидка действует только сегодня. Завтра и послезавтра курс можно будет купить только за 4000р