Недавно начал свое знакомство с языком Python с целью применения его для написания в короткие сроки приложений, выполняющих необходимую задачу здесь и сейчас. Так как планируемые приложения могли быть запущены не только на ос, в которых установлен сам Python, было решено собирать exe. Почитав пару топиков на хабре и комментарии к ним, пришел к выводу, что для этих целей прекрасно подойдет pyinstaller. Он довольно прост в использовании, но все же некоторые повторяющиеся моменты можно сократить.

pdb – Интерактивный отладчик

Версии Python: 1.4 и выше

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

Anki — это программа для запоминания иностранных слов. Список её преимуществ перед аналогами впечатляет! Судите сами:

• Широкие возможности по настройке вида карточек
• Поддержка мультимедиа
• Большое количество плагинов
• Настройка алгоритма обучения
• Подробная статистика
• Поддержка большинства современных платформ (Linux, Windows, Mac, iPhone, Android, список можно продолжить!)
• Синхронизация данных

И всё бы хорошо, да вот только благодаря таким обширным возможностям, в Anki может быть не так просто разобраться. Надеюсь, мой скринкаст вам в этом поможет.



Официальный сайт — ichi2.net/anki
Программу можно найти в Центре приложений Ubuntu.

На написание данной заметки натолкнула одна интересная статья “Anchoring effect”. Однако это совсем не перевод, так как в тексте встречается много лишней информации и исследований в духе «Британские ученые доказали…» Это скорее творческая интерпретация.

В статье описывается один очень важный психологический эффект – эффект якоря или эффект привязки.

В чём секрет?

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

Чтобы что-то оценить, нам необходима отправная точка, некий якорь – что-то вроде «розовой обезьяны».

Например, если спросить – сколько человек составляет население Венесуэлы, что вы скажете? Растеряетесь и задумаетесь. А если задать вопрос: «Население Венесуэлы больше или меньше 65 млн?». Вопрос приобретает иной окрас, и ваш мозг подсознательно начинает опираться на упомянутую цифру, даже если она взята «с потолка». Какой ответ вы дали в первом и втором случае? Во втором случае названное число будет намного больше, чем в ответ на первый вариант вопроса.
А между тем – в Венесуэле живет всего 28 млн человек.

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

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

Сразу скажу — топик — для тех, кто не разобрался что такое MapReduce. Для тех, кто разобрался — полезного тут ничего не будет.

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

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

Как посчитать все слова в Википедии (неправильный подход)

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

В самом простом случае мы можем завести хеш (dict, map, hash, ассоциативный массив, array() в PHP) и считать в нем слова.

$dict['word1'] += 1

Но что делать когда память под хеш кончится, а мы посчитали только одну сотую всех слов?

Перевод статьи Тима Ферриса из его блога.


(Учебник Дзюдо Окано Исао, который я использовал для изучения японской грамматики)

Изучение языка не должно быть сложным.

Принципы когнитивной нейронауки и управления временем могут быть применены для достижения свободного владения языком на разговорном уровне (в данном случае определяется как 95%+ процентов понимания и 100% выразительных возможностей) в течение 1-3 месяцев.

[FF D8]

Вам когда-нибудь хотелось узнать как устроен jpg-файл? Сейчас разберемся! Прогревайте ваш любимый компилятор и hex-редактор, будем декодировать это:

Специально взял рисунок поменьше. Это знакомый, но сильно пережатый favicon Гугла:

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

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

[FF D8] — маркер начала. Он всегда находится в начале всех jpg-файлов.

Следом идут байты [FF FE]. Это маркер, означающий начало секции с комментарием. Следующие 2 байта [00 04] — длина секции (включая эти 2 байта). Значит в следующих двух [3A 29] — сам комментарий. Это коды символов ":" и ")", т.е. обычного смайлика. Вы можете увидеть его в первой строке правой части hex-редактора.

В издательстве Apress вышла книга Beginning Python Visualization: Crafting Visual Transformation Scripts, посвящённая визуализации данных с помощью Python и смежных инструментов. Это уникальная в своём роде работа, потому что на Питоне такие вещи делают довольно редко. Автор книги говорит, что сам искал такое руководство для своей работы, но не нашёл, и ему пришлось разбираться самостоятельно.

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

Самое главное в книге — подробная демонстрация, как работать с известными для визуализации математических и научных данных MatPlotLib, NumPy и SciPy, а также с библиотекой PIL (Python Imaging Library) для простейшей обработки изображений.

Полистать книгу можно в магазине Amazon (по ссылке выше).

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

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

Интересно, что в далеком 1998 году читатели журнала «Software Development» признали Стива одним из трех наиболее влиятельных людей в отрасли разработки ПО наряду с Биллом Гейтсом и Линусом Торвальдсом.

Если говорить коротко, то Steven C. McConnell — программист и автор книг по разработке ПО.

Он написал книги «Rapid Development» (1996), «Software Project Survival Guide» (1998), «Professional Software Development» (2004). Журнал «Software Development», кстати, дважды удостоил его книги премии Jolt Excellence как лучшие книги года о разработке ПО.

Кстати, вы наверняка слышали фразу «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете». Так вот, эту фразу приписывают именно Стиву.

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

Да, это он в 1998 году продал свою компанию Viaweb интернет-гиганту Yahoo, которая впоследствии назвала этот продукт Yahoo Store. Да, это он основал венчурный фонд Y Combinator. Да, это его журнал BusinessWeek включил в список 25 наиболее влиятельных людей в Сети за 2008.

Хотите читать по-настоящему интересные аналитические статьи? Вам однозначно к Полу. Я настоятельно рекомендую прочитать его заметки. Особенно если вы it-шник. Особенно если вы собираетесь открывать свой бизнес.

Emacs. Большая и сложная программа. Ему как ничему другому подходит это определение. Эмакс был создан очень давно в лаборатории искуственного интллекта MIT, он несет в себе гены очень своеобразной культуры лисп-хакеров былых времен. С тех пор он не раз переписывался, улучшался, дополнялся и обрастал тысячами расширений в течение десятков лет. Эмакс, если и был когда-то мощным текстовым редактором, сейчас стал некоей универсальной программой, в нём можно делать абсолютно всё что угодно, если это хотя бы немного затрагивает собой задачу отображения или редактирования текста, и даже больше. Людям знающим универсальность играет на руку, ведь одной программой можно делать тысячу разных дел, при этом не прилагая усилий для переучивания к разным интерфейсам. Людей, впервые запустивших эмакс подобная универсальность и непривычный интерфейс поначалу пугает. Научиться пользоваться эмаксом, понять его идею и проникнуться ею задача непростая, трудоемкая и долгая (как говорится, пологая кривая обучаемости).

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

А ведь может быть не только красиво, а ещё и удобно!

Поэтому я хочу рассказать о Compiz Fusion (бывшем Beryl) — композитном оконном менеджере, который занимаеться визуальными эффектами в Linux. Только рассказать не со стороны wow-эфекта и 3д-рюшечек, а о том, как при грамотной настройке с его помощью можно добавить максимум удобства и юзабилити к своей любимой системе.

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

Апплет — это маленькое приложение, встраиваемое непосредственно в панель GNOME. Обычно апплет выполняет какой-то опеределенный узкий функционал (изменение громкости, монтирование устройств), что выгодно отличает его от громоздкого оконного приложения. На самом деле знающему Python кодеру не составит труда написать собственный апплет, но и для незнающих есть выход: большое количество полезных (и не очень) апплетов лежит на сайте gnomefiles.org, помимо этого, на официальном сайте есть примеры написания апплетов на C.

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

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

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

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

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

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

Некоторое время назад в одном из обсуждений я упомянул о том, что контрол «a-la ribbon» (который был использован в MS Office 2007 для организации меню) легко и непринуждённо реализуется средствами Qt.

Я не хочу спорить о том, удобен ribbon или нет (сам я больше склоняюсь ко второму мнению). Но на его примере можно отлично раскрыть возможности каскадных таблиц стилей для Qt (которые были представлены в Qt 4.2), чем я и займусь. Сразу прошу прощения: я не дизайнер, поэтому с точки зрения эстетики мой QRibbon скорее всего не дотянет до своего собрата от МС, но дизайнеры в МС, полагаю, в своей области превосходят меня на 2 головы, да и человеко-часов, думаю, там было затрачено в слегка побольше. Я же всего лишь демонстрирую общий принцип и базовые возможности.

Так как я сейчас изучаю язык Python, то для демонстрации был выбран именно он, но для C++ всё делается абсолютно так же. Заранее прошу прощения: Python я только-только изучаю, поэтому код может быть полон корявостей, так что прошу больно не пинать :)

Итак, начнём!

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

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

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

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

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