Ненавижу программирование! А нет, ненавижу проект.

Достал меня один проект — идет туго, делать неинтересно, даже начал думать, что программировать надоело, но переключился на свой проект туду листа (77 голосов, вы вообще дикие 🫡). Мне сразу жить захотелось! Развиваться и делать!

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

В общем, делайте, что по кайфу, а что не по кайфу не делайте 😎 Ну хоть иногда..

Не надо так — глобальные переменные

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

1. Конфликты с другими глобальными переменными. Это рано или поздно случится, поверь.
2. Отладка — пойди  найди в файле на пару тысяч строк что с твоей переменное произошло и кто ей воспользовался.
3. Модульность. Опять же, найди в большом файле все строки, которые имеют отношение к твоей переменной и попробуй их выделить в модуль — будет весело

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

P.S. Всем спасибо! Очевидно, рубрике быть 🫡

#badPractices

Дебаггер в DevTools

Вроде как штука многим известная, но мало кто её использует. Но ведь js — не приговор, можно прогать как в нормальных других ЯП

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

Чтобы войти в дебаггер нужно либо щелкнув на вкладку debugger, либо через консоль, нажав на имя и строку ошибки/лога

use strict — надо, Федя, надо

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

use strict приводит нас к стандарту ES5, но что конкретно это значит?

1. Нет замалчиванию проблем. Больше нельзя будет случайно создать глобальную переменную myVar = 10, нельзя будет добавить повторяющиеся параметры в функцию function badFunc(a, a) {...} и т.д.
2. Минорная оптимизация производительности. Улучшение скорости работы — не главная фича строгого режима, но если это ничего не стоит...
3. Исправления безопасности. Некоторые методы (типа caller) стали приватными, запретили присваивать значения свойствам, предназначенным для чтения

А если с этим кодом еще кто-то работать будет... Лучше поставить "use strict"; чтоб потом креститься на код не пришлось

​Велосипеды мои любимые

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

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

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

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

​Про синдром самозванца

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

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

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

В общем, не бойся показаться дураком и не заставляй других чувствовать себя дураками, Love&Peace

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

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

Но я мальчик, который выжил, у меня получилось! Помимо того, что я спамил по 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 ночи. Игнор всегда бесит. Если ты сейчас не можешь ответить — напиши, что ответишь через час/утром. Так клиент останется услышанным, он будет знать, что ты не забил и ответишь ему.

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

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