Как уже многие могли заметить, в последнее время компания Opera постоянно удивляет благовоспитанную общественность: то Unite-революцию затеет, то вдруг ни с того ни с сего ошарашит десятикратным (или уже больше?) приростом в скорости работы браузера, а уж про всякие нововведения в интерфейсе или в поддержке будущих веб-стандартов можно упоминать чуть ни еженедельно. Бывают и сюрпризы с отрицательным эффектом, после которых пользователи устают крутить колесо мыши, просматривая списки исправленных багов в очередной еженедельной сборке. В общем, у всякого здравомыслящего человека возникает резонный вопрос: чёрт возьми, да что там у них в этой Норвегии творится?!

Два года назад, работая над Awesome, я присоединился к разработке XCB, который является частью инициативы Freedesktop. Мне пришлось изучить тайны протокола X11 и весь древний и таинственный мир, окружающий его.

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

Нина Цепляева, Рекрутер на инженерные позиции, Google Россия

Кандидаты часто задают нам вопрос — каким должно быть правильное резюме для Google. Поэтому мы решили рассказать, на что обращают внимание рекрутеры в нашей компании.

#1 Не пишите мало. Не пишите много.
Идеальное резюме — это 1-2 страницы текста, из которых сразу понятно, что знает и умеет делать человек.
Старайтесь максимально конкретно обрисовать ваш опыт работы за последние 5-7 лет. Используйте только факты.
Не пишите сочинение: оно “отяжелит” резюме и нам сложно будет отделить важное от очень важного.
Не пишите о том, в чем не очень хорошо разбираетесь. На собеседовании наши инженеры могут начать задавать вам вопросы по предметам, с которыми вы не очень хорошо знакомы, и это негативно скажется на оценке вас как кандидата.

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

#3 Образование и опыт.
Начнем со структуры: располагайте события от нового к старому. Текущее место работы на странице должно находиться над предыдущим.
Попытайтесь перечислить только самые значимые проекты, самые важные и интересные, которыми хотелось бы гордиться. Опишите цель проекта, используемые технологии, вашу роль в нем, его длительность и результат.
Перечисляя компании, где вы работали, расскажите нам, пожалуйста, чем эти компании занимаются, по возможности укажите ссылки на корпоративные сайты.
Укажите, где вы получили образование, на каком факультете учились в ВУЗе, какой у вас средний балл в дипломе.
Если у вас имеются публикации, расскажите нам о них.

#4 Достижения.
Если вы участвовали в олимпиадах или каких-либо научных соревнованиях, напишите нам о них: что за мероприятие, какое место вы заняли.
Если вы придумали что-то новое (какую-нибудь программу, алгоритм, изобрели велосипед, самопропалывающиеся грядки, самоналивающийся кофе и т.п.), обязательно расскажите нам об этом. Мы очень ценим кандидатов, способных придумать что-то новое и воплотить это в жизнь.
Помните, что для нас важны ваши способности, ваши знания и опыт, а не громкие названия занимаемых должностей. Если вы любите заниматься разработкой и никогда не были менеджером, не стесняйтесь этого! Многие люди не хотят управлять другими и являются при этом прекрасными специалистами в своей области.

#5 Увлечения.
Расскажите нам о своих хобби и увлечениях — о том, как вы проводите своё свободное время, чем интересуетесь, какие книги любите читать, на каких инструментах играете.

Для подачи резюме в Google нужно составить его на английском языке и отправить, перейдя по ссылке: Software Engineer — Moscow

Разговорный английский язык — это обязательное требование ко всем кандидатам, подающим резюме в Google.

В мире существуют тысячи CMS для самых разных целей, самого разного качества, самой разной перспективы, стоимости, распространённости и так далее. Серьёзно опробовать их все — нереально. Поэтому когда я только знакомился с миром движков для сайтов, выбирать приходилось наугад. Ниже я опишу свои впечатления от знакомства с теми или иными движками для тех или иных целей. К некоторым приложу краткое описание особенностей, впечатление о прочих состоит только из заглядывания в админку. Заметки эти составлялись и редактировались в течении долгого времени, но сейчас я решил, что лучше опубликовать их в нынешнем виде, чем ещё полгода-год по чуть-чуть редактировать не добавляя ничего принципиально нового.
Преимущество отдаётся бесплатным движкам. Платные будут рассматриваться только для сравнения или от безысходности, т.е. если нет бесплатных аналогов. Также ограничение на технологии: php. О движках на перле и питоне я не более чем слышал, на шарпе и джаве имел дело с самописными.
Итак, рассматриваются

• CMS общего назначения. Информационные сайты, визитки, блоги…
• Многофункциональные монстры.
• Галереи.
• Социальные сети.
• Форумы.
• Интернет-магазины.

Не так давно на сайте Engadget появилась статья, написанная специалистом по законодательству в области авторского права, в которой подробно объяснялись некоторые вопросы относительно лицензии на стандарт H.264. Она довольно объемна, поэтому приведу здесь только некоторые, заинтересовавшие лично меня, моменты, в свободном изложении в виде вопросов и ответов.

Что это за MPEG-LA, которая отвечает за лицензирование этой технологии?

Данный топик описывает простую и быструю кастомизацицию Ubuntu LiveCD.
Включает в себя:
— установку дополнительных пакетов
— настройку прокси сервера и TimeZone

Несколько раз мне уже приходилось собирать свой LiveCD. Один для загрузки по сети с набором необходимых инструментов, другой для записи на DVD с полной поддержкой японского языка и дополнительного ПО. При сборке я руководствовался вот этой ссылкой https://help.ubuntu.com/community/LiveCDCustomization. Всё выходило замечательно за исключением затраченного времени. Такая ручная сборка иногда может занять несколько часов, особенно если предыдущая делалась достаточно давно.

В последний раз я решил не собирать руками а воспользоваться описанной на Хабре Ubuntu Customization Kit (http://habrahabr.ru/blogs/ubuntu/77331). К сожалению на тот момент, а это было несколько дней назад, версия 2.0.12 не заработала (ругается на отмонтирование .gvfs) на Ubuntu 10.04. Версия из trunk-а, на которую я возлагал надежды, так же не заработала, но уже с другой ошибкой.

В результате я решил больше не возиться с Ubuntu Customization Kit, а написать свой скрипт на основе WIKI статьи с help.ubuntu.com, который покрывает мои потребности и следует принципу KISS. Рабочая версия скрипта и описание под катом.

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

Вот размещённые в Викитеке переводы всех шести современных лицензий (всё это только простые переводы, не путать с дополнительной адаптацией лицензий к законам РФ):

• Creative Commons Attribution 3.0 Unported (сравнить с оригиналом)
• Creative Commons Attribution-ShareAlike 3.0 Unported (сравнить с оригиналом)
• Creative Commons Attribution-NoDerivs 3.0 Unported (сравнить с оригиналом)
• Creative Commons Attribution-NonCommercial 3.0 Unported (сравнить с оригиналом)
• Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported (сравнить с оригиналом)
• Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported (сравнить с оригиналом)

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

Все знания, которые мной были получены за это время, я «материализовал» в проекте компании, в которой собственно я работаю.

Изучая спецификацию OpenID и прочих его расширениях (SREG, AX) и надстройках, мне пришла идея разработать JavaScript виджет со своим API-прослойкой, в помощь другим разработчикам нежелающим «коротать» дни и ночи изучая спеки различных способов авторизации и их расширений.

Собственно об этом далее.

Забавная статья была буквально недавно опубликована на Хабре: «100 долларов в час».
Статья, по-моему, является незнанием или непониманием автора базовых экономических принципов, забывая про которые, он выстраивает свою теорию.

Несостоятельность теории

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

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

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

Для написания ТЗ я задался вопросом поиска простого и удобного средства создания прототипов веб-страниц. Хотелось чего-то бесплатного и в онлайне, некой альтернативы Axure. Такой сервис удалось найти, его я и предлагаю вашему вниманию. Итак, встречайте www.gomockingbird.com – сервис, позволяющий создавать очень красивые прототипы легко и удобно.
Помимо представления самого сервиса, этим постом хотелось также привлечь внимание общественности к полезной практике прототипирования.

Когда человек работает за компьютером, он смотрит в монитор и видит там разные программы. Мы подумали: «А что, если сделать так, чтобы программы тоже могли смотреть на человека большими ясными глазами?!» Так появился набор бесплатных глазастых иконок Лупоглазики 2, которыми можно заменить стандартные значки популярных приложений.



Если вы не знаете как заменить иконки в Windows или в Mac OS X, то у нас для вас есть инструкция.

Дело было вечером, делать было нечего… Дернуло меня поглядеть на QtScript, на котором пишутся плагины для Амарока, ну, думаю, просто смотреть неинтересно — надо чего-то написать. Ну, а так как я в это время слушал музыку именно из Контакта, так как не для кого не секрет, что там можно найти практически все, то было решено заменить совсем неудобный плеер контакта на Амарок, дабы была возможность нормально этим делом управлять посредством мультимедийныйх клавиш и да и просто для объединения в один плейлист композиций локальных и сетевых.

Не секрет, что многие, до сих пор, прописывают тэги во всяких cp1251 и KOI-8R — после чего их не понимают ни телефоны, ни плееры (некоторые) и с проигрывателями под linux бывает много проблем.
Больше всего неприятно, то что при загрузке новой музыки, ты не можешь быть уверен в какой кодировке идут тэги и вот добавив в свой проигрыватель ты обнаруживаешь нечитаемые символы вместо названия трека, исполнителя и альбома. А ведь оно еще и на last.fm скроблится в таком виде.

Можно использовать EasyTag и прочие редакторы тэгов.
Но чаще всего, мне надо только поправить кодировку, а тэги прописаны верно.

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

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

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

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Содержание

Списки. Свёртка списка (reduce). Прохождение по списку (range, xrange и enumerate). Проверка всех элементов списка на выполнение условия (all и any). Группировка элементов нескольких списков (zip). Еще несколько операторов для работы со списками. Продвинутые логические операции с типом set.
Словари. Создание словаря с помощью именованных аргументов. Преобразование словаря в список и обратно. «Dictionary Comprehensions».

После написания статьи о потребностях «продажников» в CRM, я стал более плотно заниматься этой темой + на мое удивление, мне пришло много предложений от хабраколлег написать такую систему и вместе ее продавать, посмотреть на их, уже готовую CRM-ку.

Напомню, что мои основные требования были: online + удобство + малая цена

Кому интересна тема CRM применительно к небольшим компаниям — мои находки и мысли на этот счет.

Итак, что же такое CRM и кому и зачем она нужна. По сути CRM нужна не только отделу продаж, но и всем сотрудникам компании, которые связаны с работой с клиентами. В больших компаниях (телеком, банки) это такие большие системы как Oracle Siebel, MS Dynamics CRM и прочие монстры. В таких системах помимо автоматизации операционной работы (завести контакты, вести учет переговоров, выставлять счета и заводить кейсы) существует много наворотов типа BI, маркетинговых кампаний или совместной работы.

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

1. База аккаунтов (организаций) и контактов
2. Возможность быстрого доступа к ней лучше online
3. Ведение истории переговоров
4. Напоминалки (типа, через 3 месяца не забыть позвонить клиенту)
5. Ведение протоколов встреч, записи звонков, короче видеть всю историю взаимоотношений

Под катом хорошие варианты:

Скриптик выглядит как-то так:

#!/bin/bash
token=$(curl -s www.google.com/accounts/ClientLogin -d Email=user.name@gmail.com -d Passwd=qwerty -d accountType=GOOGLE -d service=writely -d Gdata-version=3.0 |cut -d "=" -f 2)
set $token
curl --silent --header "Gdata-Version: 3.0" --header "Authorization: GoogleLogin auth=$3" "http://docs.google.com/feeds/user.name@gmail.com/private/full" | tidy -xml -indent -utf8 -quiet > /tmp/gdocs.xml
file=(doc1 doc2 doc3 doc4)
resourceId=(document:0ASpnxqo7zPlfZGQ3Z2Zwc183NWZteDNiM2Y ...) # и ещё 3 resourceId
i=0
while (( i < 4 )) # match num_files
do
wget --header "Gdata-Version: 3.0" --header "Authorization: GoogleLogin auth=$3" "https://docs.google.com/feeds/download/documents/Export?docID=${resourceId[$i]}&exportFormat=txt" -O /tmp/${file[$i]}.txt

sleep 2
i=$i+1
done

А теперь, как принято, разоблачение.

У книги Карла Фогеля «Producing open source software» замечательная обложка (см. выше). На ней показано множество маленьких стрелок разного размера, указывающих направо, и бо́льшая стрелка жёлтого цвета, на мой взгляд показывающая итоговый эффект. Она как бы говорит нам: если все лошади будут тащить в одном направлении, можно будет передвинуть на другое место целый дом.

Я понимаю ее именно так, потому что она напоминает мне кучу разных рисунков, которые делались на занятиях физики. Если шар ударяется о другой вот так и под вот таким углом, куда упадёт ботинок? Что-то такое.

Это красивая картинка, и именно так я представлял себе опенсорс, пока не стал в нём участвовать. Все люди тащат проект в одном направлении, чтобы сделать энциклопедию, или операционную систему. Но, скажу я вам, это совсем не так, пока проект не вырос

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

Amy Editor

Созданый в 2007 Петром Кронторадом (Petr Krontorad), Amy Editor продвинутый редактор с интерфейсом в стиле Mac. Amy Editor имеет в наличие кучу полезных опций, такие как нумерация строк, подсветка синтаксиса, сниппеты для более чем 20 языков, совместное использование и прочее.

» http://www.amyeditor.com

От переводчика

Представляю вашему внимаю перевод статьи Shalabh Chaturvedi «Be Pythonic», рекомендованной в этом топике. Если мое начинание будет поддержано, планирую также перевести две остальные упомянутые там статьи этого автора.

Вступление

Эта статья предназначена для новичков в Python.

При переходе с одного языка на другой некоторые вещи для вас могут остаться неизвестными (см. Transfer of Learning). То, что вам известно о других языках, может быть не всегда полезным в Python. Эта статья содержит некоторые используемые в Python идиомы, которые мне особенно нравятся. Я надеюсь, читатели найдут их полезными для овладения языком.