Пишу про разработку вообще и в частности про: JavaScript, HTML5, CSS3, AngularJS, ReactJS, Agile, Bitcoins

Делаем prop для проверки moment в React

Несколько специфическая тема, однако стоит взять на заметку, если пишите под React. Как известно в реакте вы можете определять типы данных, которые ожидает получить компонент. Обычно вы будете это делать с использованием prop-types, однако, если вам нужно что-то специфичное, то придется писать проверку самому.

Например, тип данных moment. Можно, конечно в общем виде написать, что ожидается объект, но мы ведь хотим все сделать красиво, поэтому нужно написать проверку.

Итак, propType это функция, которая должна бросить ошибку, если тип данных не совпадает, в противном случае она может ничего не возвращать (ну либо undefined, что по сути то же самое). Все достаточно прозаично:

Использовать так propType можно как обычно:

Однако, мы не можем сделать его обязательным, так как привыкли в стандартных propTypes. Для этого нужно добавить метод isRequired. Ну и что бы два раза не вставать давайте решим задачу в общем виде и напишем обертку для всех последующих propTypes:

В итоге isMoment будет выглядеть вот так:

Поделиться:

Вышел Chrome 61

Несколько ярких моментов:

  • Добавлена поддержка web modues 🎉
  • Появился USB API – теперь из браузера можно получить доступ к подключенным через USB устройствам 👍

Ссылки по теме:

Поделиться:

Генераторы статичного сайта

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

staticgen

Вот как раз сейчас думаю посмотреть поближе. Меня, конечно, больше интересует hexo, так как он и популярен и написан на js.

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

Upd
Ага, создается впечатление, что есть поддержка тегов:

Ссылки по теме:

Поделиться:

Обязательные переменные функции

Интересный пример как обязать разработчика использовать переменные в функции. Если на чистоту, то я явно пока не представляю как это можно применять. Ну понятно, что взять и засунуть в некую функцию, но что бы вот так остро стояла необходимость “заставить” разработчика передать переменные… что-то не встречал.

С другой стороны в академических целях очень интересно посмотреть. Потом вполне может пригодится в каком-нибудь другом случае.

Ссылки по теме:

Поделиться:

Спам hr рассылки

В продолжение предыдущего поста хочется развить тему. Тем более что все здесь присутствующие когда-то искали, и скорее всего будут искать в будущем работу. Господам (и немногочисленны дамам) бизнесменам то же может быть интересно, так что не переключайтесь.

Поговорим об одном конкретном проявлении поиска работников. А именно “спам рассылки”. Я имею ввиду массовую рассылку предложений о работе. Обычно такая рассылка минимально кастамизированна – вначале указано ваше имя и обычно вакансии в вашей сфере. Хотя, конечно, бывают и проколы, но я об этом уже писал в предыдущем посте, так что не буду повторяться.

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

hr-main

Так вот на мой взгляд это самый неэффективный способ поиска сотрудников. Рекрутер надеется исключительно на случай и на законы больших чисел – чем больше спама пошлёшь, тем больше вероятность что кто-то откликнется. При таком подходе, после того как человек откликается, его в любом случае нужно снова рассматривать и пропускать через весь процесс собеседований, потому что вы о нем вообще ничего не знаете. Такой кандидат только чуть-чуть лучше программиста который бы откликнулся на вообще случайную спам рассылку.

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

И я вот думаю – встречаются ли рекрутеры, которые ответственно относятся к этому процессу? Думаю что да, как же иначе, в связи с этим ещё один вопрос – мне было бы интересно поговорить об их процессе, мне кажется есть большой неосвоенный пласт рекламных возможностей для поиска релевантных сотрудников. Не понятно почему это никто не использует, может я что-то упускаю?.. Вот и хочется поговорить 🙂

Поделиться:

Подбор цвета

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

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

🚴 А велосипед помогут изобрести вот эти инструменты:

adobe-color-cc

https://color.adobe.com/create/color-wheel/

 

colorschemedesigner

http://colorschemedesigner.com/csd-3.5/

PS
Проблема конечно не только в графиках, просто именно эта темой я последнее время занимаюсь.

Поделиться:

Java != JavaScript

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

js-java

У меня есть теория. Скорее всего рекрутеры не просматривают руками резюме прежде чем слать вакансии. Наверняка это дело автоматизированно и когда-то какой-то “джуниор hr” меня занёс в список java-разработчиков. Ну а что java и JavaScript это ведь почти одно и тоже. Вот с тех пор спам-рассылка новых вакансий обо мне и не забывает.

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

Поделиться:

Разбор сжатого js кода – рекламные попапы

Да, да, я понимаю, рекламные попапы – это зло. Не спорю ни разу, но я хочу поделиться с вами этим видео не потому что хочу помочь в развитии спама в интернете (тем более что и не помогу, проверьте сами 😉 ). Гораздо важнее посмотреть как автор разбирается с кодом. Очень интересный анализ – автор интересно и терпеливо разбирает все по полочкам.

Суть в чем – есть определенная категория сайты, которые очень не против использовать всплывающие окна с рекламой. Понятное дело, что ни один нормальный сайт себя так вести не будет, но мы же не о нормальных говорим. Так вот браузеры с этим активно борются и открыть всплывающее окно не так-то просто. Дополнительная проблема еще и в том, что выгоднее открыть окно не поверх всех, а под основным браузером. При таком подходе есть сразу несколько профитов:

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

В общем своя логика в этом есть. Однако, выполнить это не так-то просто, потому что браузеры особенно плохо на это реагируют. Скрипты, которые могут такое проворачивать могут стоить достаточно много. Но, заниматься этим, конечно все равно не стоит – тут сразу -100500 в карму.

Вместе с тем, разобраться как это может работать весьма интересно, так что поехали (кстати, видео на английском, держитесь):

Поделиться:

Давайте наймем фронтенд разработчика – работа с git’ом

Этим постом хочется открыть новую рубрику “Давайте наймем”. Вам приходилось искать нового сотрудника в команду, такого, чтобы все знал и не требовал внимания, чтобы все сроки в срок и денег не много? Не приходилось? Не скромничайте, если вы и сами не нанимали, то в процессе либо участвовали, либо наблюдали за ним на расстоянии вытянутой руки, я все знаю 🙂

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

На работу я пока фронтенд разработчика, не ищу, однако, посмотрев вокруг, мне кажется имеет смысл обсудить какие требования стоит выдвигать к представителю этой профессии. (Как-то странно говорить о неком сферическом фронтендере в вакууме. Я же сам фронтенд пишу. Ну да ладно.) Часть пунктов, разумеется, будет перекликаться и с другими программистами, но это нормально – профессии смежные, куда ты денешься с подводной лодки.

gitПрежде чем въедливый читатель начнет беспокоиться о том, что я выдвигаю много требований. Сразу оговорюсь – я описываю не джуниора. Если вы только начинаете свой тернистый путь программиста, то с вас и спрос другой. Однако, если вы уже 3-4 года на рынке, то у меня будут к вам определенные требования. Вы ведь тоже не пойдете на зарплату джуниора 😉

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

Ну и покончив с формальностями, давайте поговорим о деле. А на деле и на повестке дня у нас сегодня “мерзавец”, если вы еще не в курсе, то именно так переводится слово git. Без него, понятное дело никуда, давайте смотреть, что хочется от кандидата, что значит “Опыт работы с гитом” в моей интерпретации:

  • Знать что такое git-flow.
    Это широкое понятие, может варьироваться от команды к команде и тем более отличаться у разных компаний. Однако, нужно знать, что рекомендуется сообществом и чем это отличается от того что применялось на предыдущем месте работы.

  • Что такое код-ревью.
    Командная работа с кодом это залог успеха (прямо так и хочется вырезать эту надпись и повесить на стенку, шучу, шучу). В код-ревью помимо технической части еще и много эмоций. Не все легко реагируют на комментарии братьев-программистов на свою работу, а код-ревью именно про это. Если программист к этому не готов, либо не в курсе, что это такое, то вас могут ждать неожиданности.

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

  • Как (и когда) делать ребейз и чем он отличается от мерджа.
    В принципе это вопрос того как каждая команда (или вся компания) решают работать с гитом. Кто-то не против ребейза, кто-то не хочет “менять историю” и для него чем больше мерджей, тем лучше. Какого-то резкого предпочтения у меня нет. Этот пункт больше для обсуждения философии вопроса.

  • Как делать фиксап и чем он отличается от сквоша.
    Работа с коммитами в полный рост. Самое время уточнить у кандидата умеет ли он манипулировать деревом коммитов в гите. Я точно против засорения истории невнятными коммитами.

  • Как именуются бренчи и как это привязано к работе с “системой отслеживания ошибок” (Jira), которая использовалась в компании.
    Гит неразрывно связан с фичами и багами, собственно, для этого мы его и держим – для того чтобы вести параллельную разработку нескольких решений в одном приложении. Очень хочется услышать, что человек понимает это и может об этом поговорить.

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

Поделиться:

Илюзорный план разработки

Очень хочется чтобы план разработки был прямым как след ракеты – строго вверх и никаких вариантов, чтобы все было на своих местах и было бы известно заранее. Стоит ли говорить, что даже ракеты строго по прямой траектории не летают, а план разработки так вообще вещь не простая.

(Хм, вы обратили внимание, что я сравнил разработку приложений с разработкой ракет? Наглость – второе счастье 🙂 )

Другими словами хочется что бы все было вот так:

app-illusional-development

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

app-development

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

Как-то так:

app-development-extreme

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

Успехов в разработке! 😉

Поделиться: