Введение.

Python замечательный язык. Связка Python + NumPy + Matplotlib, на мой взгляд, сейчас одна из лучших для научных расчётов и быстрого прототипирования алгоритмов. Но у каждого инструмента есть свои светлые и тёмные стороны. Одной из самых дискутируемых особенностей Python является GIL – Global Interpreter Lock. Я бы отнёс эту особенность к тёмной стороне инструмента. Хотя многие со мной не согласятся.

Если кратко, то GIL не позволяет в одном интерпретаторе Python эффективно использовать больше одного потока. Защитники GIL утверждают, что однопоточные программы при наличии GIL работают намного эффективнее. Но наличие GIL означает, что параллельные вычисления с использованием множества потоков и общей памяти невозможны. А это достаточно сильное ограничения в современном многоядерном мире.

Один из способов преодоления GIL при помощи потоков на C++ был недавно рассмотрен в статье: Использование Python в многопоточном приложении на C++. Я же хочу рассмотреть другой способ преодоления ограничений GIL, основанный на multiprocessing и shared array. На мой взгляд, этот способ позволяет достаточно просто и эффективно использовать процессы и разделяемую память для прозрачного параллельного программирования в стиле множества потоков и общей памяти.

Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта

О чём это всё

Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.

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

RabbitMQ позволяет взаимодействовать различным программам при помощи протокола AMQP. RabbitMQ является отличным решением для построения SOA (сервис-ориентированной архитектуры) и распределением отложенных ресурсоемких задач.

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

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

Тем не менее, когда задача «создать искусственный интеллект» была поставлена впервые, под ИИ подразумевалось нечто иное. Сейчас эта цель называется «Сильный ИИ» или «ИИ общего назначения».

С самого начала сентября широким потоком хлынули на Хабр публикации об успешном успехе на тему «Детство программиста», «Как стать программистом после N лет», «Как я ушёл в IT из другой профессии», «Путь в программирование» и так далее. Подобные статьи пишут постоянно, но вот сейчас они пошли как-то особенно кучно. Каждый день пишут то психологи, то студенты, то ещё кто-нибудь.

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

Тема шаблонов проектирования достаточно популярна. По ней снято много роликов и написано статей. Объединяет все эти материалы «анти-паттерн» Ненужная сложность (Accidental complexity). В результате примеры заумные, описание запутанное, как применять не понятно. Да и главная задача шаблонов проектирования – упрощение (кода, и работы в целом) не достигается. Ведь применение шаблона требует дополнительных усилий. Примерно так же, как и Unit тестирование.

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

Каждый раз перед собесом я говорю себе: "Спокойно, не нужно ничего выдумывать, доучивать и врать, твоих знаний и опыта достаточно для того, что бы работать у них. Ты усилишь любую команду, тебе есть что предложить, а пробелы в твоих знаниях — приемлемы. Если бы они знали о твоих навыках всё, что знаешь ты, они бы точно тебя взяли". Но когда начинается собеседование, я всегда перестаю в это верить. Все два часа интервью я хожу как по минному полю, что бы не дай бог не спалиться, что я чего-то не знаю.

Хабр, привет.

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

Метод главных компонент (PCA)/SVD

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



SVD — это способ вычисления упорядоченных компонентов.

Полезные ссылки:

• scipy.linalg.svd
• sklearn.decomposition.pca

Вводный гайд:

• Учебное пособие по основному анализу компонентов

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

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

Уже давно сформулировал для себя этот подход. Возможно, он очевиден, но хуже от этого не становится.

Сначала сами пункты.

Никогда не требуйте и не хвалите сотрудников за:

• вовремя приходят на работу или с обеда
• ходят в соответствии с дресс-кодом
• задерживаются на работе, работают на выходных

Это не все и примеры специально выбраны простые и очевидные, но для объяснения хорошо подходят.

Обратите внимание, что речь не только про «не хвалите», но и про «не требуйте».

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

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

А теперь почему так? Ведь хорошо, когда сотрудник не опаздывает и ходит в офис не в рваных джинсах?

Новая подборка советов про Python и программирование из моего авторского канала @pythonetc.

← Предыдущие подборки


Если у экземпляра класса нет атрибута с заданным именем, то он пытается обратиться к атрибуту класса с тем же именем.

>>> class A:
...     x = 2
...
>>> A.x
2
>>> A().x
2

Если вы читаете эту статью, вероятно, вы уже знакомы с возможностями, которые открываются при использовании API (Application Programming Interface).

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

Ровно 15 лет назад, в этот самый день, своими дрожащими коленками я переступил порог офиса небольшого провинциального интернет-провайдера. Моя первая настоящая работа в качестве программиста. Знаний почти нет. Тонкий испуганный голосок откуда-то из желудка советует развернуться и убежать подальше, пока окончательно не опозорился. Глубокий вдох-выдох, и вот генеральный директор уже ведет меня в небольшую комнатку-подвальчик, показывает на полуразобранный компьютер, видавший лучшие времена: «Это твое рабочее место. Устраивайся». Так началась моя карьера.

Но перенесемся в настоящее. Сейчас я пишу эти строки, сидя в удобном офисе престижного БЦ в центре Москвы. За плечами работа с крупными международными брендами и разработка сложных fintech приложений. Сотни книг прочитано и десятки статей написано. Мания величия давно вылечена. Менеджерские позиции опробованы и отвергнуты. Душевное равновесие найдено. Любовь к профессии сохранена. Однако это не статья из серии “Какой я молодец. Делай, как я и тоже будешь молодцом”. Эта статья о том, какие ошибки я совершал и что можно было сделать лучше. Эта статья — ретроспектива моей карьеры.

Привет, я Катя, я не работаю уже год.



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

У вас когда-нибудь было такое состояние?


Хочу показать вам, как TDD может улучшить качество кода на конкретном примере.
Потому что всё то, что я встречал при изучении вопроса, было довольно-таки теоретическим.
Так получилось, что мне довелось написать два практически идентичных приложения: одно писалось в классическом стиле, так как я ещё не знал тогда TDD, в второе — как раз с использованием TDD.

Ниже я покажу, где были самые большие различия.

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

Оказалось, я не один такой и схожие ощущения возникают у многих моих коллег. И тогда я решил, что либо научусь писать нормально, либо пора менять профессию. Я попробовал test-driven development в попытке что-то изменить в своём подходе к программированию.

Забегая вперёд, по результату нескольких проектов, могу сказать, что TDD даёт более чистую архитектуру, но при этом замедляет разработку. И подходит не всегда и не всем.

Мы все знакомы с различными супергероями и их уникальными способностями, хотим мы того или нет. Потому вопрос о том, какую бы вы хотели иметь суперспособность, не такой и редкий. Кто-то хотел бы быть невероятно сильным, как Халк, кто-то — быстрым, как Флеш, а кто-то не отказался бы от суперспособности Бэтмена — денег. А вот те, кто хоть раз находился в пробке длиной от Марса до Венеры, все бы отдали за возможность телепортироваться. Концепция телепортации звучит весьма увлекательно с точки зрения научной фантастики, однако в реальности эта суперспособность также существует, но наделены ею далеко не люди. Сегодня мы с вами познакомимся с исследованием, в котором ученые из Йокогамского университета (Япония) смогли телепортировать информацию внутри алмаза. Как ученые это сделали, каким боком тут квантовая физика, и что это значит для будущего технологий хранения данных? Ответы ждут нас в докладе ученых. Поехали.

От переводчика: перевели для вас статью Илада Леева о переходе с Python на Go. Статья будет полезна не только начинающим программистам, но и всем, кто так либо иначе интересуется Go.

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

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

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

Автор иллюстрации — Magdalena Tomczyk

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