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



Большинство резюме работодатель отклоняет, просто пробежав их по диагонали. Это немного обескураживает, правда? Так что очень важно, чтобы он сразу увидел нужные ему знания и навыки у вас. Сейчас подходящее время прокачаться, особенно если вам нечем похвастаться в своём резюме. Не нужно посещать университет, чтобы получить новые навыки: нужно просто идти в нужном направлении и не отклоняться от него.

TypeScript — стандарт современной фронтенд-разработки. Согласно исследованиям State of JavaScript, TS вызывает явный интерес у программистов. По данным опроса за 2019 год, почти 60% респондентов пробовали TS и продолжают использовать, 22% не пробовали и желают изучить.

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

Дамы, господа, сегодня отличный день!

Скорее всего вы помните, что существует такая форма компьютерного искусства как «демосцена», но если слышите это слово впервые — просто прочитайте тематический хаб и теги на Хабре, а также пару популярных статей по этому вопросу.


Одной из форм соревнования на демосцене является sizecoding — программирование визуальных эффектов в крайне ограниченном объеме машинного кода. Прежде чем мы перейдем к достижениям сегодняшнего дня (а они есть и более чем масштабные), давайте очень быстро пробежимся по наследию дедов. Все приведенные ниже работы сделаны в разные годы, объединяет их требование к платформе — PC, x86, DOS (никакого GPU, обычная видеокарта). В идеале вам стоит поставить DosBox и запускать каждую работу самостоятельно, благо авторы не особенно озадачиваются созданием видео и загрузкой его на YouTube. Мы постарались выбрать по одной показательной работе в каждой номинации.

На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).

Ее основными тезисами были:

• GitFlow противоречит тезису "ветки должны быть короткоживущими".
  Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
• GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
  Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
• GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
• GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)

• Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.

  
  

  Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.

  
  

Так что делать-то?

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



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

Материал, перевод которого мы сегодня публикуем, посвящён рассказу о 10 React-компонентах.

Где-то в недрах Хабра нашлась совершенно прекрасная фраза о том, что отношение работодателей к удаленной работе в России «в чём-то похоже на высказывания консервативной публики про людей с иной сексуальной ориентацией или гендерной идентичностью». Выражение: «Я вполне нормально отношусь к удалённой работе – однажды наш сотрудник переехал, но мы продолжили с ним работать удалённо» – напоминают мне фразу: «Я вполне нормально отношусь к геям, у меня даже несколько друзей геев». То есть, вроде бы вполне прилично, но в то же время явно видно, что в иных обстоятельствах человек предпочел бы не иметь дел с указанными категориями.

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

Ни для кого не секрет, что на данный момент существуют различные подходы к обработке, хранению, фильтрации и анализу больших данных. В отдельный класс можно выделить системы, построенные на событийной архитектуре (Event-Driven Architecture). Данные системы призваны решать различные задачи, в том числе в режимах близких к реальному времени. Одной из таких задач является обнаружение (детектирование, идентификация) сложных цепочек связанных событий на больших входных потоках данных (FlinkCEP — Pattern Detection). Обычно, данная задача, решается системами комплексной обработки событий (CEP), которые должны обрабатывать сотни, а порой и тысячи определенных пользователем шаблонов на входном потоке данных в поисках определенного события, аномалий, системах мошенничества и даже предсказании будущего на основе текущих событий. В статье речь пойдет о библиотеке FlinkCep Apache Flink, которая позволяет решать подобные проблемы.

Привет, Хабр! Представляю вашем вниманию перевод статьи «How to Build and Deploy a Full-Stack React-App» автора Frank Zickert.

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

Хотите стать full-stack разработчиком? Full-stack приложение дополняет интерактивный веб-интерфейс React сервером и базой данных. Но такое приложение требует гораздо больше настроек, чем простое одностраничное приложение.

Меня зовут Константин Щеглов, я занимаюсь коммерческой веб-разработкой с 2001-го года, а последние 13 лет активно участвую в формировании команд и подборе сотрудников в технические департаменты компаний, в основном занимающихся мобильной, веб- и телеком-разработкой, и сегодня хотел обсудить некоторые тонкости построения карьеры в ИТ на начальном этапе, когда у вас еще нет опыта.

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

С помощью Angular можно сделать всё что угодно. Или почти всё. Но иногда это коварное «почти» приводит к тому, что разработчик губит время, создавая обходные решения, или пытаясь понять, почему что-то происходит, или почему что-то не работает так, как ожидается.



Автор статьи, перевод которой мы сегодня публикуем, говорит, что хочет поделиться советами, которые помогут Angular-разработчикам сэкономить немного времени. Он собирается рассказать о подводных камнях Angular, с которыми ему (и не только ему) довелось встретиться.

Можете использовать этот пост как аргумент при переговорах.



Вы, наверное, уже слышали эту продуманную фразу, которую произнес Рид Хастингс, CEO компании Netflix, говоря о развитии компании: «Наш главный конкурент – это сон». Он логично рассуждает, что с точки зрения прибыльности его бизнеса, сон, занимающий треть всего времени – огромный ресурс, за который можно побороться. Но если мы дорожим своим здоровьем, красотой и жизнью, то он не должен получить от нас ни минуты от нашего сна. Мы всё еще настолько недооцениваем сон, что этот факт удивителен сам по себе. Почему мы считаем сон чем-то, чем можно жертвовать, что можно сжимать, над чем можно издеваться? Даже простейшее популярное представление о биологии говорит нам, что природа не стала бы требовать от нас трети жизни на что-то неважное.

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

Между тем, мы действительно не знаем, почему мы спим. Да, у нас есть объяснения – насчет консолидации памяти, обучения, восстановления сил и прочее. Сам вопрос остается открытым и задается вновь и вновь, потому что мы подозреваем, что это не все, что мы знаем про сон.

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

На протяжение многих лет в США была распроcтранена практика требовать претендентов на различные вакансии не только резюме, но еще и сопроводительное письмо (cover letter). В последние годы важность этого аспекта начала снижаться – уже в 2016 году сопроводительные письма требовали только около 30% работодателей. Это нетрудно объяснить – у HR-специалистов, проводящий первоначальный скрининг, обычно слишком мало времени, чтобы читать письма, на анализ самих резюме по статистике уходит всего несколько секунд.

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

Я нашла интересный пост о том, как сегодня следует подходить к написанию cover letter при поиске работы в США, и подготовила его адаптированный перевод.

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

Разработчики соединяют людей.
Разработчики помогают людям.
Разработчики дают людям возможности.

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

Приветствую, хабровчане!

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

Привет, %username%

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

Но я не хочу перечислять то же самое. Я не хочу меряться дозами LD₅₀ и претендовать на оригинальность.

Я хочу написать про те яды, с которыми ты, %username%, имеешь большой риск столкнуться каждый день. И которые не так просты, как их ближайшие собратья.

Врага надо знать в лицо. И надеюсь — будет интересно. А если окажется интересно — то возможно, что и осилишь вторую часть.

Итак — моя смертельная десятка!

Автор материала, перевод которого мы публикуем, недавно выпустил своё первое мобильное приложение, написанное на React Native. Так случилось, что это приложение стало и его первым проектом, который он создал как программист-фрилансер. Здесь он расскажет о том, с чем ему пришлось столкнуться в ходе работы — от инициализации проекта до его публикации в App Store и Google Play.

Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

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

• Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
• Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
• Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
• Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.

Недавно мы сделали то, о чём грезят все программисты и дизайнеры — переписали всё с нуля: полный редизайн нашего сайта и написание «движка» с чистого листа. Ниже поведаем о мотивации и процессе миграции с онлайн-CMS на статику.

Использование SVG-картинок в качестве плейсхолдеров — это очень неплохая идея, особенно в нашем мире, когда чуть ли не все сайты состоят из кучи картинок, которые мы пытаемся асинхронно подгружать. Чем больше картинок и чем более объемные они, тем выше вероятность получения различных проблем, начиная от того, что пользователь не совсем понимает, а что же там собственно грузится, и заканчивая известным скачком всего интерфейса после прогрузки картинок. Особенно на плохом интернете с телефона — там может и на несколько экранов все улететь. Именно в такие моменты заглушки приходят на помощь. Еще один вариант их использования – это цензура. Бывают такие моменты, когда нужно скрыть от пользователя какую-то картинку, но хотелось бы сохранить общий стиль страницы, цвета и место, которое картинка занимает.

Но в большинстве статей все рассуждают о теории, о том, что было бы неплохо инлайново вставлять все эти картинки-заглушки в страницы, а мы сегодня посмотрим на практике, как можно генерировать их на свой вкус и цвет с помощью Node.js. Мы создадим handlebars-шаблоны из SVG-картинок и будем из заполнять разными способами, начиная от простой заливки цветом или градиентом и заканчивая триангуляцией, мозаикой Вороного и использованием фильтров. Все действия будут разбираться по шагам. Полагаю эта статья будет интересна начинающим, которым интересно, как это делается, и нужен подробный разбор действий, но и опытным разработчикам возможно приглянутся некоторые идеи.

В данной статье я хочу рассказать о небольшом и забавном проекте выходного дня по передаче файлов через анимированные QR коды. Проект написан на Go, с использованием Gomobile и Gopherjs – последний для веб-приложения для автоматического замера скорости передачи данных. Если вам интересна идея передачи данных через визуальные коды, разработка веб-приложений не на JS или настоящая кроссплатформенность Go — велкам под кат.