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

Выбор библиотеки и типа алгоритма сортировки не всегда прост, а нововведения меняются в быстром темпе. На данный момент документация Pandas не соответствует коду (хотя лично мое PR-обновление сортировочных опций было самым последним).

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

UPD 17 июля 2019: В результаты оценки теста скорости теперь входят реализации GPU PyTorch и TensorFlow. TensorFlow также включает в себя результаты CPU как при tensorflow==2.0.0-beta1, так и при tensorflow-gpu==2.0.0-beta1. Интересные наблюдения: графический процессор PyTorch буквально летает, а GPU TensorFlow оказался медленнее CPU TensorFlow.

Контекст

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

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

• Полную беспроводную автоматизацию всего освещения.
• Установил кнопку «выключить всё».
• Сделал возможным полное удаленное обесточивание квартиры (включая и сам сервер управления вместе с контроллером) и обратное удаленное включение.
• Применил электронакладки (устройства поворота) для кранов на воду.

Подъездный щит жилого дома с оборудованием для удаленного обесточивания квартиры

Если вы знакомы с объектно-ориентированным программированием, то наверняка слышали и о принципах SOLID. Эти пять правил разработки ПО задают траекторию, по которой нужно следовать, когда пишешь программы, чтобы их проще было масштабировать и поддерживать. Они получили известность благодаря программисту Роберту Мартину.

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

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

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

Ну, приступим.

Я думаю, многие из Вас слышали мнение о том что кода в контроллерах быть не должно, и потому контроллер с методами в одну строку считаются «Best Practice».Я в свою очередь сомневаюсь в том, что польза от этого так уж велика. Если у Вас возникали похожие мысли, прошу под кат.

В конце мая в нашем инстаграм-аккаунте выступала Наталья Теплухина — Vue.js core team member, GoogleDevExpret и фронтенд-разработчица. Мы анонсировали ее как Senoir, но за неделю до прямого эфира ее повысили и она стала первым Staff Frontend Engineer в Gitlab.

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

Делимся расшифровкой и записью эфира.

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

• всем кандидатам задавать одинаковые вопросы,
• вопросы должны быть такие, чтобы на них ответил и junior, и senior, но по разному,
• после трёх вопросов должен быть понятен уровень кандидата.

И вот такие три вопроса для Java-разработчиков у меня получились.

Сайт Texas Internet Consulting. Жив с 1987 года, страница — 7 Килобайт.

Помните время, когда главная больше 90 Килобайт считалась расточительством? С тех пор Интернет стал жирным. И понадобились инструменты, чтобы правильно раздавать трафик сразу с нескольких узлов. Например, во время очередного обновления Fortnite CDN от Akamai сумел переварить трафик мощностью в 106 Терабит в секунду. Давайте пробежимся по основным принципам этой технологии и потенциальным проблемам.

И о том, почему Minecraft в Казани тормозит, если не развернуть сервер в черте города.

В чем отличается взгляд на карьеру у разработчика и его руководителя

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

Чего хочет разработчик

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

Как он хочет развиваться? А вот так:

• Изучать новые технологии
• Решать более интересные задачи
• Участвовать в новых проектах
• Поменьше заниматься деятельностью, не связанной с разработкой
• Принимать решения самостоятельно

В то же время его руководитель хочет:

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

Хотите знать, как добиться компромисса? Добро пожаловать под кат.

Приветы! Запилили новый выпуск с задачками, направленными на повышение нейропластичности мозга.



Вдохновлялись собеседованиями в американский Walmart. Ну что, готовы пошевелить извилинами?

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

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

Привет, хабр! Продолжаю делиться полезными подборками. Совсем недавно я опубликовал 2 поста с перечнем Github репозиториев: Часть1 и Часть2. На этот раз предлагаю вашему вниманию подборку полезных книг для разработчиков. Кому интересно — добро пожаловать под кат.

Хабра-сообщество провело еще одно интервью в нашем образовательном проекте: прямых эфирах c ребятами из IT, которые отвечают на ваши вопросы в формате живого общения.

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

В начале недели наши вопросы отвечал Борис Янгель — ML-инженер Яндекса, который участвовал в создании мозгов «Алисы», а теперь делает беспилотные автомобили. 

Боря рассказал о том, как стать крутым Data-Scientist, как парашютный спорт помогает ему в работе, почему конференции по ML бесполезны и ответил на недавний пост разгневанного отца про то, как Алиса рекомендовала видео с историями убийств ребенку.

Автор статьи, перевод которой мы публикуем сегодня, старается постоянно совершенствовать свои JavaScript-знания и навыки. Он хочет рассказать о том, как, стремясь к профессиональному росту, строит свою работу.

ML.NET претендует на звание самой мощной библиотеки для машинного обучения на платформе .NET. Так ли это на самом деле? На вопрос отвечает Джефф Просайз.

Джефф Просайз — один из создателей компании Wintellect, коллега по цеху знаменитого Джеффри Рихтера, автор более девяти книг и множества статей по разработке приложений, сейчас работает с Azure и разрабатывает различные AI-решения.

Под катом перевод и видео доклада Джеффа с конференции DotNext 2019 Moscow в оригинале.

Доброго времени суток, друзья!

Представляю вашему вниманию перевод статьи «JavaScript Visualized: Promises & Async/Await» автора Lydia Hallie.

Приходилось ли вам сталкиваться с JavaScript кодом, который… работает не так, как ожидается? Когда функции выполняются в произвольном, непредсказуемом порядке, или выполняются с задержкой. Одна из главных задач промисов — упорядочение выполнения функций.

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

Хочу поделиться с сообществом своим недавним опытом поиска работы, сообщить, так сказать, вести с передовой. Несмотря на то, что все написанное – абсолютно субъективно, заметка будет полезна для других IT-шников. Особенно – если они интроверты и редко ходят по собеседованиям.

А еще, полагаю, многим будет любопытно, какая метаморфоза произошла с рынком работы в связи с последними событиями.

← предыдущие главы

51. Выбираем компоненты конвейера: простота решения задач

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

Первые 70% курса по SQL кажутся довольно простыми. Сложности начинаются на остальных 30%.

С 2015 по 2019 годы я прошёл четыре цикла собеседований на должность аналитика данных и специалиста по анализу данных в более чем десятке компаний. После очередного неудачного интервью в 2017 году — когда я запутался в сложных вопросах по SQL — я начал составлять задачник с вопросами по SQL средней и высокой сложности, чтобы лучше готовиться к собеседованиям. Этот справочник очень пригодился в последнем цикле собеседований 2019 года. За последний год я поделился этим руководством с парой друзей, а благодаря дополнительному свободному времени из-за пандемии отшлифовал его — и составил этот документ.

Есть множество отличных руководств по SQL для начинающих. Мои любимые — это интерактивные курсы Codecademy по SQL и Select Star SQL от Цзы Чон Као. Но в реальности первые 70% из курса SQL довольно просты, а настоящие сложности начинаются в остальных 30%, которые не освещаются в руководствах для начинающих. Так вот, на собеседованиях для аналитиков данных и специалистов по анализу данных в технологических компаниях часто задают вопросы именно по этим 30%.

Удивительно, но я не нашёл исчерпывающего источника по таким вопросам среднего уровня сложности, поэтому составил данное руководство.

Привет, меня зовут Александр Васин, я бэкенд-разработчик в Едадиле. Идея этого материала началась с того, что я хотел разобрать вступительное задание (Я.Диск) в Школу бэкенд-разработки Яндекса. Я начал описывать все тонкости выбора тех или иных технологий, методику тестирования… Получался совсем не разбор, а очень подробный гайд по тому, как писать бэкенды на Python. От первоначальной идеи остались только требования к сервису, на примере которых удобно разбирать инструменты и технологии. В итоге я очнулся на сотне тысяч символов. Ровно столько потребовалось, чтобы рассмотреть всё в мельчайших подробностях. Итак, программа на следующие 100 килобайт: как строить бэкенд сервиса, начиная от выбора инструментов и заканчивая деплоем.



TL;DR: Вот репка на GitHub с приложением, а кто любит (настоящие) лонгриды — прошу под кат.

Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

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

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

Снова браться за мелкие заказы с апворка Паша не стал и впервые задумался о релокации. Так он оказался в Минске — там он собирает команду, чтобы открыть локальный офис израильской компании.

Паша пришёл к нам на подкаст, обсудил с нами найм и индустрию и даже устроил что-то вроде показательного собеса (которое пошло не совсем хорошо).