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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

Google в официальном блоге, а также на самом сайте Google Reader объявил о закрытии сервиса.

Среди причин было названо желание сфокусироваться на основных продуктах и улучшить их.
Дата закрытия сервиса: 1го июля 2013.

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

P.S. Среди онлайн альтернатив сервиса могу назвать Яндекс.Ленту и NetVibes.
Предложите свою альтернативу в комментариях.

UPD: Вы можете подписать петицию Keep Google Reader Running

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

Пример кросс-авторизации

Вернемся в 2005-й год и представим, что мы пишем социальную сеть. В ней имеется форма импорта контактов из адресной книги GMail. Что нужно для доступа к контактам GMail? Конечно, логин и пароль от ящика. Но если мы попросим ввести их на нашем сайте, пользователь заподозрит неладное. Где гарантия, что мы не сохраняем на сервере введенные пароли? Поэтому нам хочется, чтобы пароль вводился только на сайте GMail, и после этого доступ к контактам через API GMail предоставлялся нашей социальной сети (возможно, на время).

Вместо предисловия

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

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

Привет.
Это топик о том, как относительно быстро и безболезненно настроить секционирование (партицирование) таблицы по месяцам, если вы используете Django+PostgreSQL. Многое из описанного подойдёт и для других фреймворков и ORM.

О том, что такое секционирование и зачем оно нужно, можно почитать, например, здесь, здесь и здесь.

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

Каждый раз писать запросы для включения секционирования не очень хочется, так что попробуем автоматизировать. Хорошо, если на выходе получится что-то, что может использовать и не сильно знакомый с SQL человек. I've read the docs, so you don't have to.

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

Введение.

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

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

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

Данная статья написана под влиянием книги Дэвида Коупленда «Build Awesome Command-Line Application in Ruby» (купить, скачать и изучить дополнительные материалы). Большая её часть будет посвящена проектированию дизайна CLI-приложений вне зависимости от используемого языка. По ходу будут обсуждаться и вещи специфичные для ruby, но не страшно, если вы его не знаете, кода будет не слишком много. Можно считать эту статью довольно подробным обзором вышеупомянутой книги с вкраплениями собственного опыта. Книжку рекомендую!

Для начала я задам вопрос. Если посмотреть на сообщества IT-шников, можно заметить, что несмотря на обилие программ с красивым графическим интерфейсом, приложения командной строки остаются весьма популярны. Почему?
Ответов несколько. Во-первых, это красиво удобно — если вы можете описать задачу командой в командной строке, то её гораздо проще автоматизировать, чем если вам приходится анализировать передвижения мыши и клики на разные пункты меню. Во-вторых, это даёт возможность комбинировать программы невероятным числом способов, чего сложно добиться с помощью графических интерфейсов.
В значительной степени философия Unix базируется на том принципе, что множество маленьких утилит, каждая из которых умеет делать свою конкретную задачу — это лучше, чем одна многофункциональная программа-универсал. И это одна из причин успеха Unix-систем в мире IT-шников.
Наверное, каждый понимает, что обычного пользователя вряд ли удастся сманить от GUI к CLI, давайте сосредоточимся на нас, «компьютерщиках» и конкретизируем наши пожелания к CLI-приложениям.

Здравствуйте, хабражители!

В далеком декабре прошлого года я впервые столкнулся с Data Protection Application Programming Interface (сокращенно DPAPI). Тогда я изучал способ хранения логинов/паролей в браузере Chrome. Я обещал, что распишу эту систему подробно и на пальцах. Негоже врать, поэтому добро пожаловать под кат!

Часто путают терминал и шелл. В тех же *nix есть шеллы (bash, csh, zsh, …) и терминалы (konsole/guake/yaquake/tilda и т.д. и т.п.) Для мира Windows общеизвестный терминал только один – стандартное консольное окошко, которое часто ошибочно называют «cmd.exe». И мало кто знает о существовании множества других эмуляторов терминала. Известных шеллов больше, их целых два: cmd.exe и powershell.exe. И хотя есть как минимум три порта bash (MinGW, CygWin, GIT) многие юниксоиды предпочитают ругать cmd.exe.

Меня не устраивал ни один из найденных альтернативных терминалов (как в 2009-м, когда я начал работу над ConEmu, так и сейчас). Казалось бы требований немного, вот основные:

Итак, что же это значит, когда кто-либо говорит, что foo выглядит как pythonic? Что значит, когда кто-либо смотрит в наш код и говорит, что он unpythonic? Давайте попробуем разобраться.

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

Напротив, метка unpythonic означает, что код представляет собой грубую попытку записать код какого-либо другого языка программирования в синтаксисе Python, а не идиоматическую трансформацию.

Понятие Pythonicity плотно связано с минималистической концепцией Python’a и уходом от принципа «существует много способов сделать это». Нечитабельный код, или непонятные идиомы – все это unpythonic.

При переходе от одного языка к другому, некоторые вещи должны быть «разучены». Что мы знаем из других языков программирования, что не будет к месту в Python’e?

В этой статье я хотел бы рассказать о том, как создать полноценное приложение на Python для Android. Нет, это не очередной мануал для создания скрипта для sl4a, это мануал по созданию полноценного приложения с UI, возможностью собрать apk и выложить на Android Market. Заодно я хотел бы похвалиться своим первым приложением на google.play, это не hello world, а полезное приложение для фотографов, хотя и узко специализированное.

Предисловие

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

Введение

Это заметка, в которой я хотел бы немного описать архитектуру и систему расширений среды разработки Qt Creator. Изначально, я предполагал лишь перевести документ Writing-Qt-Cretor-plugins.pdf, но так уж вышло, что развитие Qt Creator не стоит на месте и во первых, данный документ уже не столь актуален (сам устарел, API поменялось, куски кода не полные и часто не работают), а во вторых со времени его написания появлись дополнительные возможности расширения Qt Creator, которые хотелось бы описать.

Тем не менее, не будь этого документа, не было бы и данной заметки: из него я взял очень много, вплоть до структуры поста, при этом постаравшись где-то что-то выкидывая/заменяя/добавляя сделать пост актуальным для последней на текущий момент времени версии Qt Creator 2.4.0.

Кому может быть полезен данный документ? В первую очередь это конечно же Qt-программисты, которые выбрали данную IDE как основную среду разработки.

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

Итак, что же нас ожидает под катом (жирным отмечены готовые разделы):

1. Сборка Qt Creator
2. Первое расширение
3. Добавление новых меню и пунктов меню
4. Архитектура Qt Creator
5. Добавление нового редактора (Editor)
6. Добавление боковой навигационной панели
7. Добавление страницы в диалог настроек
8. Добавление фильтра в диалог поиска
9. Добавление нового типа проекта

Напомню, что Qt Creator является кросс-платформенной свободной IDE для работы с фреймворком Qt, разработанной Trolltech (Nokia). Что не мешает сделать из него простой текстовый редактор с подсветкой синтаксиса, простым отключением всех расширений. Внимание, сотни картинок!

Эта статья не для матёрых укротителей Python’а, для которых распутать этот клубок змей — детская забава, а скорее поверхностный обзор многопоточных возможностей для недавно подсевших на питон.

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

Что учёные, писатели и программисты думают о популярных языках программирования.

Все языки

«Есть два подхода к программированию. Первый — сделать программу настолько простой, чтобы в ней очевидно не было ошибок. А второй — сделать её настолько сложной, чтобы в ней не было очевидных ошибок.»
Tony Hoare. Профессор, занимался реализацией Алгол 60, сейчас исследователь в Microsoft Research.

Algol 60 (позже повлиявший на C)

«Я не мог устоять перед искушением добавить в язык нулевой указатель (null), просто потому, что его так легко было реализовать. Это привело к бессчётному множеству ошибок, уязвимостей и сбоев, которые нанесли ущерб, наверное, в миллиард долларов за последние сорок лет.»
Tony Hoare.

Недавно познакомился со структурами C/C++ — struct. Господи, да «что же с ними знакомиться» скажете вы? Тем самым вы допустите сразу 2 ошибки: во-первых я не Господи, а во вторых я тоже думал что структуры — они и в Африке структуры. А вот как оказалось и — нет. Я расскажу о нескольких жизненно-важных подробностях, которые кого-нибудь из читателей избавят от часовой отладки…

Многие из нас выросли на «Танчиках», «Марио» и прочих нетленных шедеврах времён рассвета игровой индустрии. Приятно порой вспомнить, как днями напролёт резались с друзьями у экранов телевизоров, меняя джойстики как перчатки. Но время не стоит на месте, и одни интересы сменяются другими. Однако, порой любовь к старым-добрым игрушкам не угасает.
Я отношу себя к людям именно таким, и мой интерес к старым играм пошёл в сторону реверс-инжиниринга, что и привело меня в IT-сферу, где я и осел с концами.

Я хочу рассказать вам о том, что же под капотом у железных монстров из знаменитой игры Battle City (в простонародье «Танчики») с не менее знаменитой приставки Nintendo Entertainment System (сокращённо NES, в России более известен её китайский клон «Dendy»). Мне в своё время эта информация показалась довольно любопытной — надеюсь, такой же она покажется и вам.

Эта статья открывает серию статей — если окажется, что Хабраколлеги сочтут ее интересной, ибо первое правило публичных выступлений гласит: рассказывай людям о том, что им интересно!

Если вы раньше не выступали на публике или боитесь это делать — вам под кат. Если вы считаете себя опытным докладчиком, для вас будет вторая статья серии.

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

Историческая справка: на Хабре по этой теме уже было небольшое обсуждение год назад.

Profile-guided optimization (далее PGO) — техника оптимизации программы компилятором, нацеленная на увеличение производительности выполнения программы. В отличии от традиционных способов оптимизации анализирующих исключительно исходные коды, PGO использует результаты измерений тестовых запусков оптимизируемой программы для генерации оптимального кода.

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

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