​Удалённая работа стала популярным трендом, особенно в IT-сфере. Часто сталкиваюсь с мнением, что удалёнка - это панацея от проблем и несомненно лучше, чем работа в офисе. Но так ли это?

Да, с одной стороны можно не тратить время на дорогу в офис, носить любимую затёртую футболку, а самое главное – можно работать из другого города и даже страны.

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

Вообще удалёнка часто рисуется нам в виде ноутбука на пляже, но так это не работает. Даже кровать вместо рабочего стола расслабляет и убивает всю мотивацию работать, что уж говорить о жарком пляже с манящим морем. Я там напишу максимум одну строчку и это будет: "Я увольняюсь"

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

В php приведение типов — тоже штука забавная

Например

var_dump ('123bc' == 123 ); //  bool(true)

Через это можно складывать числа и даже строки

var_dump ('123bc' + 7); //  int(130)
var_dump ('123bc' + '7bc' ); //  int(130)
var_dump ('123bc' + 'b7c' ); //  int(123) приведение не сработало, потому что число должно быть вначале, перед буквами

Делать так, конечно не надо. Да и не строгое сравнение — зло, используем только ===

​Неочевидные способы улучшить свои навыки

1. Программируй на других языках, пока мозг не закостенел. Так ты сможешь быстрее находить решения нестандартных задач и не зависать над клавиатурой. Можешь попробовать Haskell, он точно тебе вынесет мозг.
2. В ту же тему – решай задачки, на codewars, например. Упарываться по несколько часов в день не нужно, конечно, но размять мозги стоит определенно.
3. Open source. Мало того, что это работа в команде, в этих проектах участвуют реально замотивированные ребята. Они работают не за деньги, а за идею. Естественно, что они помогут тебе улучшить твой код. К тому же, можешь встретить там новичка и помочь ему: когда объясняешь что-то другому человеку — начинаешь понимать предмет гораздо лучше.

​🚀 Как разговаривать с клиентом о технических аспектах проекта?

Клиент смотрит на тебя, как на пришельца с Марса, когда ты говоришь о проекте? Если да, то этот пост для тебя

♦️Говори понятным языком. Ты можешь быть гением, знающим все тонкости кода, но не все знают разницу между POST и GET запросами. Поэтому используй простые аналогии и объясняй сложные термины доступным языком. Например, сравниваешь API с официантом, который передает заказ кухне и приносит тебе блюдо.

♦️Используй визуализацию. Рисунки, схемы и презентации могут спасти мир! Они помогут тебе объяснить сложные вещи простым и ясным образом. И да, кто сказал, что нельзя добавить пару мемов для разнообразия? 😜

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

♦️ Будь терпелив и открыт. Если клиент задает много вопросов, это хорошо! Значит, он хочет понять и быть в теме. Будь готов к дополнительным объяснениям и не забывай про улыбку – позитивная атмосфера создает чудеса!

В общем, главное – быть на одной волне с клиентом и не превращать составление ТЗ в пытку.

​Баги с запахом бензина.

Что приходит тебе на ум, когда говорят программировании? Я вот представлял код на трех мониторах, святящуюся клавиатуру и пачку банкнот за каждую строчку кода. Но что как-то...

Периодически все летит к чертям, прямо в ад. Когда твой проект крашится прямо на проде, а паникующий заказчик бомбит тебя сообщениями по 30шт в минуту. И вот ты молишься, чтобы у тебя был под рукой компьютер. Но нет!

В моем случае это был беззаботный день отпуска, когда я ехал по трассе в другой город. Без ноутбука и без нормального интернета. Хвала тем заправкам на которые есть wi-fi для гостей! Мне пришлось качать на телефон ftp менеджер (я даже не знал что такие есть до этого момента) и в холодном поту пытаться исправить баг, наслаждаясь запахом 95-го бензина

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

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

Прямо наболело. Сидел и тыкал инспектор кода? Изменил 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к/наносек.

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

Почему?

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

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

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

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

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

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