​Консоль! Чего мне не хватает для фронта — так это изменения файлов прямо в браузере.

Прямо наболело. Сидел и тыкал инспектор кода? Изменил 10 парамеров, добавил 5 новых и закоментил 8 старых и наконец исправил баг? Молодец, а теперь сделай тоже самое у себя в редакторе, не ошибись только, а то опять все сначала.

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

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

​Форматированием вымощена дорога в ад

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

А через месяц и 4 коммита с правками и новыми фичами Тема понял, что все хуйня и надо алгоритм заказа возвращать назад. Задача несложная: нахожу коммит, копирую измененный код, и вставляю в актуальный файл. Да?

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

Так что учитесь на моих ошибках, форматирование - только отдельным комитом.

​Если в разработке бардак и хаос — просто скажите, что у вас Agile.

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

Agile включает в себя множество конкретный методологий, например SCRUM. Штука простая, 4 компонента:
1. Бэклог — это список TODO: все задачи, фичи и фиксы, которые нужно сделать в продукте.
2. Спринт. Это типа советской пятилетки, только на неделю. Короткий временной отрезок, за который пытаются сделать несколько задач из бэклога
3. Ежедневные митинги! Наши любимые, 15 минут любви, за которые каждый человек должен ответить на три вопроса: что сделал вчера? Что сделаешь сегодня? Нужна ли помощь и есть ли какие-то проблемы?
4. Большое совещание в конце спринта. Обсуждаем что получилось сделать, что нет. Уточняем ТODO: что добавить, что удалить. Ну и выбираем таски на следующий спринт.

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

​Топ-3 ошибки верстальщика, из-за которых я матерюсь

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

1. h1-h6
Заголовки — это семантика, поэтому как выставить заголовки решает СЕО-специалист. СЕОшники — люди вообще своеобразные, ты не угадаешь, где что поставить. Поэтому не навешивай стили на заголовки, сделай так, чтобы h1 можно было заменить на h3 и верстка не поменялась:

 <h1 class="h1">Заголовок</h1>
 <style>
 .h1{
    color: red;
 }
 </style>

Про стилизацию текста заголовками я вообще молчу...

2. Стили на user-generated content.
Частая ошибка: верстаешь ты по макету стили для статьи. Увидел ссылку и по привычке навесил на нее класс, а на класс — стиль. Проблема вскроется тогда, когда админ в редакторе создаст ссылку, на которой никакого класса не будет.
Вместо .my-link{} используй .my-article a. Здесь и заголовки стилизовать нужно и можно через теги, а не классы. Как говорится, это другое.

3. Выставление высоты.
Контент на сайте меняется и от этого верстка не должна ломаться — козаЛосьБык, это очевидно, но с вылезающим из блока текстом я сталкиваюсь постоянно.

​Почему нельзя работать без предоплаты?

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

1. Весь контроль у клиента. Слышал от знакомых историю, как клиент нанимал сразу 3х фрилансеров, чтобы постфактум заплатить тому, у кого больше понравится результат.
2. Клиент будет докапываться. Я раньше тоже брал заказы без предоплаты — это были самые ужасные клиенты, которые заставляли исправить разницу в пиксель или вообще меняли дизайн прямо у меня на глазах, во время работы.
3. Нет доверия. Во-первых, клиент не доверяет тебе, раз отказывается платить. Во-вторых, ты не можешь доверять клиенту, потому что так или иначе будешь бояться, что тебе не заплатят. Работа без доверия — это ад, оно тупо того не стоит.

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

​Не работай за дешево.

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

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

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

​Kanban

Еще одна популярная методология Agile — это канбан. В отличие от скрама канбан фокусируется не на спринтах, а на задачах.
Главная составляющая — доска с разделами todo, develop, test, deploy и дальше по вкусу. Задачи могут подкидываться и меняться каждый день, а оценка таски по времени не так важна, потому что не нужно рассчитывать сколько задач будет выполнено за спринт.

Таким образом Kanban еще более гибок, чем Scrum. Мне понравилось сравнение: скрам — это автобус, который берет таски только на остановках, а канбан — это маршрутка, которую останавливают где угодно.

​Почему твой pet проект обречен на провал?

Сколько ты начинал проектов? А сколько из них закончил? Лично у меня идей было сильно больше, чем результативных проектов. А почему?

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

— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно... — сказала Алиса.
— Тогда все равно, куда и идти.

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

Иными словами — нужен план. Пускай ты не успеешь в срок, пускай что-то не получится, но у тебя будет хотя бы карта и понимание, что делать. План просто не даст тебе месяц рисовать анимации для нового сайта с объявлениями о работе и не позволит оптимизировать на миллисекунды верстку, пока не будет разработана БД.

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

PHP, JS, паттерны, клиенты фриланса и прочая садомазахия — меня зовут Саша и я стараюсь простым языком объяснить сложные вещи. Все в плюсе: я структурирую свои знания, ты поднимашь свой прайс.

Вот посты, которые особенно сильно греют мне душу:

♦️Про синдром самозванца
♦️Клиент не шарит. И это — нормально.
♦️Баги с запахом бензина.

В общем, я fullstack laravel+vue, ко мне можно на ты, и я рад тебя тут видеть!)

👇Голосуй как давно в IT и рассказывай, на чем прогаешь👇

Неявные приколы 🤡

"Почему так?!?" — кричат джуны. "без понятия, юзай ===" — отвечают сеньеры.

На самом деле собаку опять зарыли в спецификации. При нестрогом сравнении js сначала пытается привести все к одному типу. В случае [] == 0.  Пустой массив сначала преобразовывается в строку, получается "", строка уже преобразовывается к Number, на выходе 0 == 0.

При сравнении [] == "\t" массив тоже преобразовывается в строку. Слева строка, справа строка: "" == "\t", тип один, но контент в строках разный — не равно. Вот и выходит, что
"" != "\t", "\t" != "0" и т.д. При этом, если любое выражение привести к Number — все будет 0

Кстати смайл относится не к js, а к тем, кто юзает нестрогое сравнение. Сам такой))

Небольшой оффтоп: мне интересно, как можно было переименовать твиттер, но оставить иконку скворечника, твиты вместо постов и т.д. Будет ли это вообще переделываться?

Дом, прокрастинация и котики — моя борьба за время

Смотрю налево — чай с печеньками, смотрю направо — котики в ленте, смотрю в будущее и вижу просранные дедлайны и бедность. Я не знаю, как можно отработать дома полноценные 8 часов, когда все и всё намекает на отдых и комфорт.

Сейчас мое спасение — душ и секундомер. Но, кажется, нужно будет искать что-то новое.

1. Секундомер — мне платят за часы, поэтому тикающий секундомер напрямую давит на мою совесть и не дает отвлекаться

2. Душ — моя перезагрузка, своего рода медитация. На случай, если даже секундомер не спасает от мыслей о звездах.

А где вам легче работать? дома или в офисе?

​Скилл, деньги и поменяйте цвет к кнопочки, пожалуйста

Я начинал работу с верстки, работая параллельно курьером в яндексе еде (всем говорю, что работал в яндексе). Денег платили, что там, что там одинаково мало, но я был уверен, что верстка — временно, я выучу кучу крутых фреймворков, стану сеньером-помидором и буду получать 300к/наносек.

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

Почему?

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

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

Нужно ваше мнение!

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

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

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

​Долгострой выжмет соки из тебя и твоего заказчика

У меня недавно было 2 огромных проекта от разных заказчиков.

Первый — что-то типа CRM для строительной компании заказчика, допустим, Эдуарда. Так вот фантазии Эдуарда можно позавидовать — всё новые и новые фичи залетали в ТЗ намного быстрее, чем я успевал их реализовать. Я в принципе тоже был не против. Больше работы — больше денег. С деньгами правда были проблемы — постоянно приходилось торговаться и спорить, объяснять цены и сроки, которые двигались вместе с увеличивающимся ТЗ. Да и в принципе недовольство заказчика нарастало — деньги-то в проект вкладываются, а выхлопа нет.

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

А вот со вторым повезло меньше — ситуация была похожая, но проект просто потерял актуальность, пока мы пилили его. Месяцы моей работы улетели в архив.

В общем, лучше на коленках, с багами и с половиной фич, чем вообще не сделать: Уговаривай клиента сделать сначала минималку, отбривай все фичи и переноси их на пост-релизную разработку. Выпускай MVP, а потом уже допиливай

P.S. Спасибо за ответы в предыдущем посте! Если честно, не ожидал, что так много человек заинтересуется)

Не надо так — Магические числа

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

Возьмем пример со скриншота — только сатане и автору известно, что значат эти 1, 3 и 5. А через месяц известно будет вообще только Сатане, ибо автора уже повесят за такой кодинг.

Ну и в дополнение представь, что ты решил поменять код успеха с 1 на 200 а статус проверяется в проекте 242 раза — неприятно.

Короче, код статуса, процент НДС, часы рабочей недели и т.д. — все выносим в константы, чтобы не было стыдно свой код на гит заливать.

P.S. Думаю сделать badPractices постоянной рубрикой, поставь 🫡 если интересно

#badPractices

Валидатор, уходи!

Валидатор HTML (тык, если что) — штука очень мутная. В принципе, задумка хорошая — закидываешь свою страницу на тест, тебе пишут твои ошибки и неточности и после исправления ты можешь быть уверен, что страница будет отображаться во всех бразуерах одинаково правильно.

Но по факту это просто испытание нервов кодера. Одно из первых моих заданий было исправить по валидатору около 20 страниц — на психотерапевта я потом потратил сильно больше, чем заработал 🤡

1. В реальности валидатор не гарантирует кроссбразуерность.
2. Валидатор не гарантирует хороший UX
3. Не гарантирует даже корректное отображение сайта
4. Гарантирует нервный тик
5. Даже главная страница хабра показывает 65 ошибок

Так что давайте все дружно! Валидатор, уходи!