В прошлый раз мы реализовали обновление БД.

Осталось сделать только REST-интерфейс. Давайте займёмся этим.

Введение

Эта часть будет, пожалуй, самой сложной — мы близко узнаем типажи Send и Sync, а также тонкости работы замыканий и времён жизни. По-другому я бы озаглавил её «зануда исследует, почему обязательно нужно клонировать данные». Она полезна тем, что затрагивает тонкие места Rust и показывает причины некоторых неочевидных ошибок. Так что если хотите разобраться досконально — добро пожаловать.

Также хочу отметить: если вам что-то непонятно относительно приведённого кода или сами объяснения кажутся недостаточно ясными, не стесняйтесь писать об этом в комментариях. Автор потратил не минуту и не полчаса, пытаясь понять, почему код работает именно в том виде, в котором он написан, и вынужден был не раз сходить в IRC и на форум за разъяснениями.

Часть 1: Реализуем WebSocket. Введение.

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

В первой части мы рассмотрим начальную настройку окружения и реализацию простейшего WebSocket-сервера. Чтобы понять технические детали статьи вам не потребуется опыта работы с языком Rust, хотя знание основ системных API (POSIX) и C/C++ лишним не будет. Прежде чем начинать чтение, заготовьте немного времени (и кофе) — статья описывает все максимально подробно и поэтому довольно длинная.

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

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

Перевод статьи «Most Frequent Python Problems and Solution» с сайта pamno.com.

Мы проанализировали Stack Overflow на предмет наиболее часто встречающихся проблем и резюмировали ответы.

1. Как мне проверить, существует ли файл, используя Python, без использования try оператора?

Совместимо с Python 2.x/3:

  import os

  print os.path.isfile(fname)

2. Лучший способ проверить список на пустоту

Совместимо с Python 2.x/3:

  li=[]

  if not li:

     print “empty"

Существует множество книг и статей по данной теме. В этой статье я попробую понятно рассказать самое основное.

Бинарное дерево — это иерархическая структура данных, в которой каждый узел имеет значение (оно же является в данном случае и ключом) и ссылки на левого и правого потомка. Узел, находящийся на самом верхнем уровне (не являющийся чьим либо потомком) называется корнем. Узлы, не имеющие потомков (оба потомка которых равны NULL) называются листьями.


Рис. 1 Бинарное дерево

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Всем привет.

В первой части мы сделали простейший прототип, работающий с PostgreSQL.

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

В качестве формата конфигурации я выбрал INI — достаточно простой и известный формат.

Всем привет!

Спешим поделиться видео с августовского Python Meetup. В этот раз мы прослушали два доклада: один про реализацию полнотекстового поиска при помощи Python, а второй — обзор конференции Europython 2015 из уст очевидца.

Приятного просмотра!

Это вторая статья цикла, посвященного разработке, управляемой моделями. Сегодня мы создадим метамодель, основанную на метаметамодели Ecore. Вскользь затронем моделирование данных, а именно Anchor, 6НФ и концептуальное моделирование.

Года полтора назад встал вопрос совместимости написанного кода с Python3. Поскольку уже стало более менее очевидно, что развивается только Python3 и, рано или поздно, все библиотеки будут портированы под него. И во всех дистрибутивах по умолчанию будет тройка. Но постепенно, по мере изучения, что нового появилось в последних версиях Python мне все больше стал нравится Asyncio и, скорее, даже не Acyncio а написанный для работы с ним aiohttp. И, спустя какое то время, появилась небольшая обертка вокруг aiohttp в стиле like django. Кому интересно что из этого получилось прошу под кат.

Вторая часть

Введение
Краткий обзор других фреймворков на базе aiohttp
1. Структура
2. aiohttp и jinja2
3. aiohttp и роуты
4. Статика и GET, POST параметры, редиректы
5. Websocket
6. asyncio и mongodb, aiohttp, session, middleware
7. aiohttp, supervisor, nginx, gunicorn
8. После установки, о примерах.
9.RoadMap

1. Вступление

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

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

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

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

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

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

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

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

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

В статье в ознакомительных целях рассматривается процесс создания простого хранилища простых текстовых документов на базе Riak версии 2.1.1 и организация поиска по ним с помощью Riak Search (Yokozuna). В качестве клиентской библиотеки используется официальный клиент для Erlang.

Для начала представим, что у нас есть огромное количество таких документов:

• title — заголовок;
• body — содержимое;
• tags — тэги;
• created_at — время создания;
• smiles — количество смайликов (плюсиков, лайков, как хотите)

и огромное количество пользователей, желающих их изменять. Кому интересно, начнём.

Итак, кто не против, чтобы одежду ему подбирала программа, машина, нейросеть?

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

На наш взгляд, объектный язык ограничений (Object Constraint Language, OCL) должен знать каждый, кто занимается моделированием или кому интересна модельно-ориентированная разработка. Однако, он незаслуженно обделен вниманием в сети вообще, а, уж, в русскоязычном сегменте информации просто мизер. Что это за язык и зачем он нужен, описано в этой статье. Статья не претендует на фундаментальность, полноту охвата, точность определений и т.п. Её задача: 1) на простых примерах познакомить с OCL тех, кто никогда не слышал об этом языке, 2) а для тех, кто о нём слышал, возможно, открыть новые способы его применения.

Предлагаю читателям «Хабрахабра» перевод статьи «Using the Media Capture API in the Browser» авторства Dave Voyles.



Сегодня я хочу поэкспериментировать с Media Capture и Streams API, разработанные совместно в Web Real-Time Communications Working Group из W3C и Device APIs Working Group. Некоторые разработчики могут знать их как getUserMedia — главный интерфейс, который позврляет веб-страницам получать доступ к таким девайсам, как веб-камеры и микрофоны.

«Инструкция создания функционального приложения», часть 1.

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

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

Давече мне понадобилось реализовать некое подобие собственного statsd-like сервера сбора метрики, но с несколько узко-специфичными фичами, под которые без хорошего напильника не ложилось ни одно готовое или полуготовое решение. В связи в этим было решено реализовать простой клиент-сервер протокол на python с использованием tcp/udp soket'ов. Оговорюсь, что с сетевым программированием знаком я был, да и остаюсь постольку-поскольку, хотя общее понимание tcp/ip стека имелись. Решение в лоб на синтетике показало себя замечательно, но стоило мне нагрузить его более-менее реальными данными (всего-то порядка 20к сообщений в секунду с нескольких потоков) и оно начало показывать свои подводные камушки. Наверное, я просто не смог правильно приготовить raw сокеты, но задачу нужно было решить быстро, времени на глубокое понимание и изучение сетевого программирования не было, поэтому я начал искать решения, где за меня уже хотя бы половину придумали бы. Поиск меня привел к библиотеке ZeroRPC, которая была не так давно, как я понял, выпущенна в мир из недр dotCloud.

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

Всем привет!
В июне Python Meetup исполнилось 2 года. Чтобы отметить это, мы собрались в субботу 27 июня и провели весь день вместе, общаясь и слушая доклады. Речь шла о:

• Оптимальном наименовании переменных
• Безопасном запуске чужого кода на своем компьютере
• Использовании Jenkins в тестировании игр
• Парном удаленном программировании
• Объектной подсистеме Python

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

Представляем наглядное пошаговое руководство по поиску и устранению ошибок в коде для языка Python, которое мы в Alconost перевели специально для Хабра. Следуйте по стрелкам, чтобы определить вероятную причину проблемы — и, если первое из найденных решений не подходит, возвращайтесь и пробуйте еще.

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


Картинка кликабельна

Переведено с любовью к коду компанией-локализатором Alconost.