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

Неожиданно тихо прошел релиз новой версии virtualbox, в котором впервые появилась возможность запускать в виртуальной машине MacOS X. Официально. С оригинального диска. Не хакинтош.

Пролог

Наверное всем веб (а может и не только веб) разработчикам рано или поздно приходилось сталкиваться с такой задачей как опции пользователей. Что я имею ввиду проще всего показать на картинке. Под опциями будем понимать чекбоксы (то есть опция либо есть либо нет). Обычно таких опций не слишком много, порядка 2-10. Обычно их указывают при регистрации и/или редактировании профиля.

Постановка задачи

Походу разработки какого-либо проекта как правило число этих настроек (да и сами настройки) могут варироваться, так что было бы неплохо реализовать механизм этих опций так, чтобы добавлять/изменять/удалять их было максимально просто, изменив при этом как можно меньше кода. Я расскажу как можно решить и как решил эту задачу я в рамках фреймворка Ruby on Rails.

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

Большинство опытных пользователей Windows знают про возможность ввода символа по его коду: Alt-[номер на дополнительной клавиатуре]. Самые опытные знают, что поведение различается у юникодных и неюникодных программ (юникодные хотят двухбайтный код, неюникодные — код в текущей кодировке). Особенно приятно пользоваться этим методом на ноутбуках, где дополнительная клавиатура либо отсутствует, либо доступна с использованием регистра Fn.

Большинство пользователей линукса знают о Compose key. И о том, что с её помощью можно вводить часто необходимые знаки, такие как кавычки-ёлочки (« == Compose < <, » = C > > ), тире (— = Compose ---), символ параграфа (§ = Compose s o), всякие умляуты и диакриты (àãå, Compose `a, Compose ~ a, Compose o a), символ фунта (£ = Compose L -), неразрывный пробел (Сompose и два пробела) и т.д.

Но иногда хочется вводить странные символы (например, Ѧ или забавные значки из раздела «различные символы» таблицы юникода: ☭, или даже символы других языков: シツ, あ, красивые нестандартные скобки: 【такие】 или 〘「такие」, или даже 《такие 》。

Есть унылый вариант — ковыряться в таблице символов. Интересно первые два-три раза. Дальше их хочется вводить быстрее. И этот метод есть: Ctrl-Shift-U — после этого удерживая шифт нужно ввести нужный код в шестнадцатиричном виде (т.е. 1 — 4 символа).

Сами коды можно посмотреть в той же таблице символов. Однако, метод работает только в gnome-приложениях (например, в опере с момента ухода с Qt она работать перестала). А в Inkscape оно работает даже интереснее — там после нажатия Ctrl-Shift-U в подсказке появляется будущий символ, и можно поправить опечатку в вводе кода символа.

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

Будут рассмотрены следующие средства: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Виртуализация, хотя и относится в какой-то мере к средствам безопасности, рассматриваться не будет, тем более что это отдельная обширная тема.

Я думаю многие пользуются DataBinding`ом в .NET, она же привязка данных. Она позволяет, при выделенной модели данных и независимом визуальном представлении, забыть о синхронизации данных с формой. Привязав один раз properties модели к элементам представления, мы избавляемся от десятков обработчиков onChange и подобных для изменения полей модели, а в случае изменения поля вне gui-интерфейса (например синхронизация модели с базой), мы не будем мешать уровни абстрации, чтобы обновить textBox.text. Давайте данные будут отдельно, gui отдельно. Плюс мы получаем наглядный, легко переносимый код на asp.net или даже на другой язык/платформу.

 

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

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

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

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

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

Перевод пока местами просто ужасен, и в этом исключительно моя вина за пока что отсутствующим опытом внятного перевода некоторых технических аспектов. Хотя на первый взгляд, все вроде должно быть понятно. Если знающие «матчасть» программисты мне помогут, буду очень рад. Особенно в плане терминов.

И так, предлагаю ознакомится тут.

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

Это продолжение перевода статьи Дэвида Гуджера «Пиши код, как настоящий Питонист: идиоматика Python»

Начало и окончание перевода.


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

Этот журнал посвящен Ubuntu и open source. На его страницах вы найдёте новости, руководства и обучающие статьи.

Маленькое вступление. Уверен, что каждый, кто использовал питон некоторое время, полюбил выражения в прямоугольных скобочках. В этой статье я хочу от «а» до «я» рассказать о срезах. Для начала немного о терминологии: в английском языке их называют «slice». Я буду называть их то «слайсами», то «срезами», как в моем понимании этого слова. Будем все учиться на примерах. Для меня, такой метод был бы самым удобным, быстрым и простым.

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

Учет задач мы ведем не в солидном таск-трекере, а в… текстовом файле. Точнее не просто текстовом, а в расшаренном документе Google Docs. Происходит это так:

• Записываем возникающие задачи обычным черным шрифтом в виде обычного ненумерованного списка.
• Размером шрифта отмечаем приоритет задач — чем крупнее, тем важнее.
• Цветом помечаем задачи, назначенные на конкретного человека — за каждым разработчиком закреплен свой цвет.

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

Уважаемое Хабрсообщество и все интересующиеся языком программирования Python. Я начал переводить весьма интересную книгу Gray Hat Python. Правда, пока я перевел лишь предисловие и первую главу. Начал переводить для себя (поэтому немного коряво), но все таки решил, что нужно делиться. :)

И так предоставим слово автору.

Предисловие переводчика
Эта статья продолжает серию переводов официальной документации по PHPUnit на русский язык.
Часть 1, Часть 2

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

Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».

Как можно достичь этих двух противоположных целей?

Про MongoDb было рассказано не так много, но относительно полно, например здесь. Хочу поделиться еще с одним практическим использованием этой БД — это построение цепочек друзей. Построение цепочек и концепцию кругов было использовано в Мойм Круге. Вот пример: Я — Иван Петров — Петр-Иванов — Киририлл Лавров — Вася Пупкин.

MongoDb было выбрано как высокопроизводительное хранилище данных, позволяющее быстро извлекать массивы структур данных. Традиционные key/value DB для этого не подходят, почему — поймете по ходу изложения статьи.

В данной статье рассмотрен опыт использования noSQL DB при построение «цепочек друзей» в небольшой соц-сети 300 тыс пользователей.

Введение

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


Совершенно очевидно, что сжимать сроки до бесконечности невозможно. Существует определённый предел. Например, известным экспертом в области оценки трудоёмкости разработки ПО Стивом Макконнеллом (Steve McConnell) этот порог определён как 25% от исходных оценок (см. мою предыдущую статью).
Но этот топик не об оценках трудоёмкости…
Вот я выше написал «совершенно очевидно...». Думаете, это действительно очевидно? Всем?
Мой недавний опыт показал, что это очевидно далеко не всем. Проект был очень крупный и срок сдачи неумолимо приближался. Было принято решение резко расширять команду, чтобы успеть. Довод про «9 женщин» никто не принял. Команда была расширена и в срок мы всё равно не успели. Можно ли было как-то, кроме как на словах, показать, как будут развиваться события? Вот о том, как смоделировать такую ситуацию, и будет моя статья.

Автор книги ExtJs in Action Jesus Garcia представлят очень подробный 49-минутный скринкаст с большим количеством наглядных схем, записанный за 20 часов материала, которые он представит позже