Весь прошлый год я работал с моим любимым фреймворком, Vue.js, описывал и представлял его. И я понял, что ещё не разобрался с обработкой ошибок во Vue. Мне бы хотелось объяснить это тем, что я пишу идеальный код, но мы все знаем, как обстоит дело в действительности. В течение нескольких последних дней я экспериментировал с различными методами обработки ошибок, которые предоставляет Vue, и решил поделиться своими открытиями. Очевидно, что этот обзор не охватит все возможные сценарии, но я надеюсь, что он вам поможет!

После участия в сессии State of the Union на WWDC 2019 я решил детально изучить SwiftUI. Я потратил много времени на работу с ним и теперь приступил к разработке реального приложения, которое может оказаться полезным широкому кругу пользователей.

Его я назвал MovieSwiftUI — это апп для поиска новых и старых фильмов, а также их сбора в коллекцию при помощи TMDB API. Я всегда любил фильмы и даже создал компанию, работающую в этой сфере, правда давно. Компанию сложно было назвать классной, а вот приложение — да!

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

Так получилось, что я провожу довольно много собеседований на должность веб-программиста. Один из обязательных вопросов, который я задаю — это чем отличается INNER JOIN от LEFT JOIN.

Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.

Я так устал от этих ответов с пересечениями множеств и кругов, что даже перестал поправлять людей.

Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.

Решив попробовать свои силы на зарубежном рынке, я начал отправлять резюме в различные конторы. Даже не с целью найти работу, а просто для расширения кругозора. Выбор пал на вакансии «Java Developer». Промышленного опыта работы с языком у меня нет, только личный опыт, сертификаты с Oracle Certification Center, книги и.т.д. Честно признаться, на последнем месте работы за полтора года ничего кроме «форов» и «ифов» я не писал (но это совсем уже другая история) поэтому решил, почему бы собственно и нет.

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

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

Разные помощники в написании классного кода нас просто окружают, линтеры, тайпчекеры, утилиты для поиска уязвимостей, всё с нами. Мы привыкли и используем не вдаваясь в детали, как «черный ящик». Например, мало кто разбирается в принципах работы Pylint — одного из таких незаменимых инструментов для оптимизации и улучшения кода на Python.

А вот Максим Мазаев знает, насколько важно понимать свои инструменты, и нам рассказал на Moscow Python Conf++. На реальных примерах показал, как знание внутреннего устройства Pylint и его плагинов помогло уменьшить время code review, улучшить качество кода и вообще повысить эффективность разработки. Ниже расшифровка-инструкция.

Привычный хаос в названиях коммитов. Знакомая картина?

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

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

После доклада Юры Лучанинова, я решил для себя попробовать Flutter. Чтобы мозг размять, и чтобы было о чем похоливарить с мужиками на кухне. Дело пошло. Я начал смотреть, потом читать, потом писать. И вроде все получается, приложения запускаются, и то что объясняют — понятно, все просто. Но не без “но” — объясняют не все. А поскольку платформа, ЯП, подходы и даже предметная область для меня новые, то подобное вызывает раздражение, ведь у тебя “не запускается”, а ты даже не знаешь что гуглить: Dart/Flutter/Window/Screen/Route/Widget?

Перечитывать всю документацию Dart, Flutter и его виджетов конечно же не хотелось, ведь времени у меня не много, и мне лишь хотелось присмотреться к Flutter. Вот было бы здорово, если бы был небольшой гайд, в котором описано все нужное, но не больше, для понимая и написания не слишком сложных приложений на Flutter!

Некоммерческий консорциум The Linux Foundation объявил о формировании сразу двух новых фондов: GraphQL Foundation и Ceph Foundation. Далее — подробнее о каждом из них.

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

Что такое Agile?

Agile вырос из среды веб-консалтинга, где он приносил определённую пользу: при работе с привередливыми клиентами, которые не знают, чего они хотят, обычно приходится выбирать из двух вариантов. Или одолеть клиента: установить ожидания, соответствующую оплату за переделки и поддерживать отношения равенства, а не подчинения. Или принять некорректное поведение клиента (как, скажем, приходится многим дизайнерам) и ориентировать рабочий поток вокруг клиентской дисфункции.

Это выступление состоялась 12 октября 2017 года на конференции Mirror Conf в Браге (Португалия) и ещё раз 9 февраля 2018 года на Awwwards Conference в Берлине.

Этим летом после лекции на веб-конференции у меня состоялась увлекательная беседа с молодой студенткой, которая изучает цифровой дизайн. Было интересно сравнить наши карьерные пути. У меня пятнадцать лет опыта дизайна для веб-клиентов, у неё — один год, но каким-то образом мы оказались в одинаковой ситуации: мы наслаждались работой, но были совершенно дезориентированы и обескуражены быстро растущей сложностью всего вокруг. Что за ерунда произошла? (Конечно, это риторический вопрос).

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

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

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



В последние годы микросервисы стали очень популярной темой. «Микросервисное безумие» выглядит примерно так:

«Netflix хороши в DevOps. Netflix делают микросервисы. Таким образом, если я делаю микросервисы, я хорош в DevOps».

Я хорошо помню то время, когда в 2001 году, спустя десятилетие после начала эры www, первый раз вышел в Интернет-сеть. Это было то волшебное чувство, когда перед тобою открывается неограниченный мир информации, который, в сравнении с теперешним, был весьма ограничен. И речь даже не о том, что не было ни социальных сетей, ни Инстаграмов, ни Youtube, большинство из этих соц. сетей лишь убивают время в наши дни, хотя некоторые и позволяют получить долю полезной информации, чем народ в них сидящий, занят далеко не всегда. Что говорить, фотографий в нормальном разрешении почти не было, про стримминг видео говорить и не приходилось, вэб был довольно простым и сайты старались писать на голом html, делая их как можно проще и легче для ускорения загрузки при использовании низкоскоростных соединений и уменьшения потребления ресурсов на стороне сервера. Но какое же хорошее это было время :)



В это же время в США уже вполне себе были распространены выделенные линии среди домашних абонентов со скоростью подключения до 768 Кбит / с и более. Ещё в 1998 году можно было обзавестись корпоративной линией c подобной скоростью в крупных городах США по цене порядка $400 / месяц, а для домашних пользователей были доступны варианты высокоскоростного Интернет-доступа от $99 за 128К канал, годом позднее уже можно было получить 384К за $40, цены постоянно снижались. В Украине, как в прочем и в РФ, был доступен в основном только дорогой и медленный Dial-Up. Выделенные линии были чем-то невероятным и позволить себе канал в 1 Мбит / с или 2 Мбит / с мог разве что Интернет-провайдер, который предоставлял доступ в сеть для абонентов посредством модемного подключения для сотен и даже тысяч абонентов. Провайдер, обладавший подключением в 1 Мбит / с в Украине или РФ, реально мог обеспечивать доступом в Интернет город с населением в 100 000+ человек. Услуга не была ещё столь массовой и % пользователей был небольшой, особенно в регионах.

tl;dr; В рекрутинге больше бардака, чем вы думаете. Расскажу четыре истории, где отличным инженерам отказали по причинам, абсолютно не связанным с их профессиональными знаниями или соответствием корпоративной культуре.

Когда люди не получают предложения о работе, то часто думают, что это их вина: «Меня отвергли три компании подряд, наверное, я никудышный инженер». Поработав некоторое время в ИТ-рекрутинге, могу вас заверить, что случайные факторы и шум (ложноотрицательные результаты) тоже играют важную роль. Часто отказы действительно вызваны случайными вещами и иррациональными причинами.

Страшилка № 1: кандидата отвергли из-за фреймворка

На позицию фронтенд-разработчика в агентстве я передал инженера, который участвовал в разработке ECMAScript и сделал значительный вклад в некоторые другие проекты open source. Мне понадобилось несколько недель, чтобы найти этого человека, и несколько часов для его правильной оценки, включая видеоинтервью (мы любим такое делать на coderfit.com). Его кандидатуру отверг программист из агентства после 10-минутного просмотра примеров кода. С ним даже не пообщались лично, а просто прислали «консерву» — шаблонное письмо по электронной почте:

«[…]Хотя ваше резюме и сопроводительное письмо очень конкурентоспособны, наши специалисты по найму рассмотрели вашу заявку и не выбрали её для дальнейшего рассмотрения. […]»

Парадный портрет автора, заодно иллюстрирующий идею современной веб-разработки

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

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

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

Но у меня нет сторонних проектов. У меня нет аккаунта на GitHub. У меня нет open-source проектов, которые я строгаю по вечерам. У меня ровно ноль пулл-реквестов в любой из последних модных проектов, в которых участвуют все крутые кодеры. Я не вожусь с упражнениями в Haskel. И я ненавижу хакатоны.

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

Здравствуйте, дорогие читатели. Если вы открыли этот пост, значит, паутинная разработка переднего края (то есть, веб фронтэнд девелопмент, я хотел сказать) трогает вас за живое. И прежде, чем вы начнете кидать помидоры благодарить рассказчика, прошу дочитать… хотя бы до середины.

На написание статьи меня подтолкнули простые причины: идет война за сердца и умы разработчиков, и многие уважаемые софтверные гиганты считают своей обязанностью облегчить участь девелопера (что хорошо, кстати). При этом не стесняясь сломать ему мозг и нервную систему (а вот это не очень). Так сказать, во имя счастья будущих поколений. Может быть, я ошибаюсь, но хочу поделиться с вами информацией об инструменте, который достаточно давно открыл для себя и с тех пор не ем кактусы, как те мыши: Mithril (MithrilJS).

Привет!

Надеюсь, вам понравится этот новый мир. Он очень отличается от мира 2007 года. Совет: если вы только что взяли ипотеку, вернитесь и отмените ее. Уж поверь мне.

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

---

Перевод статьи Sashko Stubailo GraphQL vs. REST

---

Два способа отправки данных по протоколу HTTP: в чем разница?

GraphQL часто представляют как революционно новый путь осмысления API. Вместо работы с жестко определенными на сервере конечными точками (endpoints) вы можете с помощью одного запроса получить именно те данные, которые вам нужны. И да — GraphQL гибок при внедрении в организации, он делает совместную работу команд frontend- и backend-разработки гладкой, как никогда раньше. Однако на практике обе эти технологии подразумевают отправку HTTP-запроса и получение какого-то результата, и внутри GraphQL встроено множество элементов из модели REST.

Так в чем же на самом деле разница на техническом уровне? В чем сходства и различия между этими двумя парадигмами API? К концу статьи я покажу вам, что GraphQL и REST отличаются не так уж сильно, но у GraphQL есть небольшие отличия, которые существенно меняют процесс построения и использования API разработчиками.

Так что давайте сразу к делу. Мы определим некоторые свойства API, а затем обсудим, как они реализованы в GraphQL и REST.