Причина, по которой вам, на полном серьёзе, нужно прекратить записываться на онлайн-курсы, если вы не применяете на практике то, что уже знаете.



Шли выходные. Я только что закончил ещё один онлайн-курс по науке о данных. Я чувствовал, что достиг чего-то. Ещё бы, любой почувствует, что стал настоящим специалистом в области данных, «успешно завершив» 5 разных курсов и получив «сертификаты» за каждый из них. Именно так я и считал.

Но онлайн-курсы – забавная штука. У большинства из них есть красочные описания, длинный список тем, которые они охватывают, обещания сделать из вас эксперта в одной или нескольких сферах, а если повезёт, то и отзывы людей, уже прошедших курс. Обычно в отзывах пишут про то, как этот курс спас кого-нибудь от неминуемой гибели или сделал его/её абсолютным чемпионом в предметной области. Хотя, конечно, большая часть из нас пришла сюда за другим — сертификатом о прохождении курса. Этот яркий цифровой документ, содержащий наше имя – то, что играет решающую роль для большинства участников. А затем, в один прекрасный день, мы сидим в комнате напротив нашего потенциального работодателя и понимаем, что, вопреки нашим ожиданиям, сертификаты мало кого из них впечатлили. Некоторые даже не считают нужным отнестись с уважением к времени, потраченному на получение этих сертификатов. Они сразу переходят к делу и говорят: «Эти сертификаты бесполезны, если вы не работали ни над одним проектом». Естественно, очень неприятно услышать такое. Тем более, если наши надежды на то, что это интервью пройдёт успешно, в первую очередь возлагались на пройденные нами онлайн-курсы. Мы вложили в них наши деньги, время и усилия. Наше главное оружие было разбито ещё до начала конкурсного отбора – такое ослабило бы чью угодно уверенность в себе.

Когда у меня просят совет о том как попасть в data science, я советую стать разработчиком программного обеспечения. Это мое мнение. Я бы хотел услышать контраргументы в комментариях.

Все вокруг, даже ваша бабушка, хотят стать data scientist. Может быть data science это самая сексуальная профессия 21 века, но это не значит, что нужно игнорировать отличную, высокооплачиваемую профессию разработчика.

Часто недавние выпускники и люди, меняющие профессию, спрашивают меня как попасть в data science. Я советую им стать разработчиками вместо этого.

Имея опыт в обеих сферах, я попытаюсь убедить вас, что я прав.

Вакансий на должность разработчика больше

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

Ниже представлена пара скриншотов с результатами запросов на вакансии “data scientist” и “software engineer”.



google: data scientist usa indeed



google: software engineer usa indeed

7616 вакансий в data science по сравнению с 53893 вакансиями в сфере разработки ПО. Это данные по Америке, но я думаю в других странах будет похожий результат.

Это всего лишь мое мнение. Если у вас есть контраргументы, пожалуйста, напишите их в комментариях.

Хотите стать data scientists?

Я познакомился с более 50-ю data scientists и с еще парочкой поработал лично.

Здесь я расскажу, как эти люди пришли в Data Science. Без онлайн-курсов.

1. Решите задачу с помощью машинного обучения

Выберите реальную проблему, и решите ее с помощью машинного обучения.

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

Вот примеры задач, которые вы можете попробовать разрешить:

• Распознавание фейковых новостей
• Прогнозирование стоимости жилья в вашем районе
• Подбор домашних питомцев в зависимости от образа жизни потенциальных хозяев

Если ваш решатель заработает (или даже почти сработает), создайте пользовательский интерфейс, которым можно будет пользоваться, и опубликуйте его на Hacker News или Product Hunt.

Добавьте строку с названием «Data Scientist» в резюме. Если получилось решить проблему машинного обучения, никому и дела не будет, что это было всего лишь шоу одного актера.

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

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

В предыдущей статье мы усовершенствовали системы логирования. Вместо точки доступа fanout (которая подходит только для элементарной трансляции сообщений), мы использовали direct — и получили возможность получать сообщения через определенные выборки.

Хоть direct и усовершенствовал нашу систему, он всё-таки имеет недостаток — он не может составить маршрут(routing) по нескольким критериям.

Например, нам понадобилось разделять логи не только по его типу важности, но и по источнику лога. Вы наверное встречали такую концепцию в unix инструменте syslog, которые различает логи по его типу важности(info/warn/crit...) и по его объекту (auth/cron/kern...).

Мы получаем гибкость в запросе. Например, мы может получить все логи с типом error, пришедшие из 'cron'-а, и все логи пришедшие с 'kern'. Для того, чтобы реализовать это в нашей системе логирования, изучим точку доступа — topic.

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

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

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

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Train your first neural network: basic classification".

Это руководство по обучению модели нейронной сети для классификации изображений одежды, таких как кроссовки и рубашки. Для создания нейронной сети используем python и библиотеку TensorFlow.

В мире Postgres индексы крайне важны для эффективной навигации по хранилищу базы данных (его называют «куча», heap). Postgres не поддерживает для него кластеризацию, и архитектура MVCC приводит к тому, что у вас накапливается много версий одного и того же кортежа. Поэтому очень важно уметь создавать и сопровождать эффективные индексы для поддержки приложений.

Предлагаю вашему вниманию несколько советов по оптимизации и улучшению использования индексов.

Примечание: показанные ниже запросы работают на не модифицированном образце базы данных pagila.

Автор: Вячеслав Михайлов, Solutions Architect.

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

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  
  • XML-RPC and JSON-RPC
  • SOAP
  • REST
  
  
• WebSockets APIs
• Library-based APIs
  
  • Java Script
  
  
• Class-based APIs
  
  • C# API
  • Java
  
  

Виды API по категориям применения:

• OS function and routines
  
  • Access to file system
  • Access to user interface
  
  
• Object remoting APIs
  
  • CORBA
  • .Net remoting
  
  
• Hardware APIs
  
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …
  
  

Я — PHP-Developer, живу в Стокгольме. Недавно был на собеседовании в один большой шведский сайт (более миллиарда page views в месяц). Интервью проводили 2 программиста из этой фирмы. В определенном моменте, один из них достал листок бумаги и сказал, что предлагают мне решить небольшую задачку (тут же на бумаге, без компьютера). И что у меня есть 10 мин. Попросили так же комментировать каждый шаг.

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

Зачем публикую это? Во-первых, может кому-то пригодится как хороший тест для нанимаемых разработчиков; во-вторых, кто-то, если встретит нечто подобное, будет уже полон знаний; в-третьих, может кто-нибудь поместит правильное решение в коментах?

Ниже — сама задача. Оставляю все в оригинале, как было.

За пять дней, с 24 по 28 июля 2017 года, я прошел собеседования в LinkedIn, Salesforce Einstein, Google, Airbnb и Facebook; все пять компаний предложили мне работу. Это был замечательный опыт и я понимаю, как мне повезло, что мои усилия оправдали себя, поэтому решил написать об этом. Здесь я расскажу о том, как готовился к собеседованиям, как они проходили и какое впечатление произвели на меня компании.

Как все началось

Я отработал в Groupon почти три года. Это моя первая работа, там были и прекрасные люди, и отличные проекты. Мы делали всякие интересные штуки, вводили перемены внутри компании, публиковали материалы и все в таком духе. Но со временем я стал ощущать, что темп моего самообразования стал затухать (попросту говоря, замедляться), мне не хватало пищи для ума. К тому же, как и всякого разработчика ПО из Чикаго, меня тянуло в Область залива Сан-Франциско — ведь там столько известных компаний.

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

Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.

Подобные движки используются при сложном поиске по базе документов. Например, поиск с учетом морфологии языка или поиск по geo координатам.

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

Дорогой друг, если ты готов узнать больше про архитектуры популярных кроссплатформенных мобильных фреймворков, именно в этой статье мы проведем их сравнение и определим, для какого класса задач или команд подходит тот или иной инструмент. В первой части рассмотрим общие архитектурные паттерны кроссплатформенных фреймворков, а также архитектуры PhoneGap и ReactNative. Во второй части — фреймворки Xamarin и Qt.

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

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

В данной статье я попробовал систематизировать «врожденные пороки» создаваемых людьми миров, для поиска похожих паттернов в той реальности, которая считается настоящей.

Введение

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

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

Автор материала, перевод которого мы публикуем, собрал 19 идей, которые могут оказаться полезными для тех Node.js-разработчиков, которые хотят повысить свой профессиональный уровень в 2019 году. Мир JavaScript огромен, поэтому освоить всё то, о чём пойдёт здесь речь, попросту нереально. Вряд ли найдётся кто-то, кто владеет всем этим в совершенстве. Однако кое-что в этом обзоре вполне может пригодиться именно вам.

Здравствуй, Хабр! Сегодня я хочу завершить цикл статей об организации тестирования (начавшийся с изучения ошибок и опыта), рассказав о том, как же все-таки Badoo выпускает два качественных серверных релиза каждый день. Кроме пятницы, когда мы релизимся только утром. Не надо релизиться в пятницу вечером.

Я пришел в Badoo чуть более четырех лет назад. Все это время наши процессы и инструменты для тестирования непрестанно развивались и совершенствовались. Для чего? Число разработчиков и тестировщиков увеличилось примерно в два раза — значит, для каждого релиза готовится больше задач. Количество активных и зарегистрированных пользователей тоже удвоилось — а значит, и цена любой нашей ошибки стала выше. Для того чтобы доставлять пользователям максимально качественный продукт, нам нужны всё более и более мощные средства контроля качества, и эта гонка не заканчивается никогда. Цель этой статьи не только продемонстрировать работающий пример, но и показать, что какими бы крутыми ни были ваши процессы контроля качества, наверняка можно сделать их еще лучше. Технические реализации некоторых инструментов вы сможете найти по ссылкам на другие статьи, о некоторых из них нам еще предстоит написать.

В Badoo существует несколько разных QA-флоу, отличие которых обосновано разными средствами разработки и целевыми платформами (но мы используем для них общие системы: JIRA, TeamCity, Git и т.д.), и я вам расскажу о процессе тестирования и деплоя наших серверных задач (а заодно и веб-сайта). Его можно условно разделить на 5 больших этапов (хотя тут, конечно, многие мои коллеги считают по-разному), каждый из которых включает в себя и ручную, и автоматизированную составляющую. Постараюсь рассказать вам по очереди о каждом из них, отдельно выделяя то, что изменялось и развивалось в последние годы.

Всем привет, дорогие хабрахабровцы! Недавно я начал изучать node.js и дошёл до самого интересного, а именно — Socket.Io. Поизучав информацию в интернете, я так и не смог найти подробного «гайда» по данному модулю, поэтому пришлось копать самому. Некоторые скажут, что можно и самому понять, что написано на сайте модуля, но некоторым этого будет не достаточно чтобы понять базу web-socket'ов, поэтому я решил написать эту статью для таких людей, а именно на самом 'чётком' примере — чате.

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

Вот, например, типичная задача: разработка REST API, серверной части некоего приложения. Обилие собственных возможностей Node и множество дополнительных модулей, которые способны помочь в решении этой задачи, способны завести новичка в тупик, вызванный богатством выбора. Основные вопросы здесь заключаются в подборе компонентов и в настройке их совместной работы.