Пять параметров, по которым aptitude превосходит (по четвертому параметру не уступает) apt:

1. Логичность синтаксиса. И единство управления.
2. Гибкость поиска.
3. Проставление меток пакетов.
4. Разрешение зависимостей.
5. Интерфейс.

Вчера я задал вопрос в своем ХабраБлоге — интересно ли людям узнать, что такое Hadoop с точки зрения его реального применения? Оказалось, интересно. Дело недолгое — статью я написал довольно быстро (по крайней мере, ее первую часть) — как минимум, потому, что уже давно знал, о чем собираюсь написать (потому как еще неплохо помню как я сам тыкался в поиске информации, когда начинал пользоваться Hadoop). В первой статье речь пойдет об основах — но совсем не о тех, про которые обычно рассказывают :-)

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

Что такое Hadoop?

Ну скажите, какой смысл об этом писать? Уже не раз это проговаривалось, неоднократно начинали писаться посты на тему Hadoop, HDFS и прочая. К сожалению, обычно все заканчивалось на довольно пространном введении и фразе “Продолжение следует”. Так вот: это — продолжение. Кому-то тема, затрагиваемая в этой статье может показаться совершенно тривиальной и неинтересной, однако же лиха беда начало — любые сложные задачи надо решать по частям. Это утверждение, в частности, мы и реализуем в ходе статьи. Сразу замечу, что я постараюсь избежать написания кода в рамках этой конкретной статьи — это может подождать, а понять принципы построения программ, работающих с Map/Reduce можно и “на кошках” (к тому же с текущей частотой кардинального изменения API Hadoop любой код становится obsolete примерно через месяц).

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

Некоторое время назад у меня дошли руки до темы, которая давно уже меня нервирует интересует. Эта тема — наследование в JavaScript.

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

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

Представляю вашему вниманию перевод очередного замечательного эссе Пола Грэма What Startups Are Really Like.

Октябрь 2009
(Это эссе основано на выступлении в Школе Стартапов в 2009г.)

Я не знал о чем говорить в Школе Стартапов, поэтому я решил спросить создателей стартапов, которые мы профинансировали. О чем я еще не написал?

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

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

Я с гордостью могу сказать, что получил один ответ, который гласил:

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

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

Я долго (несколько лет) не решался составить окончательное мнение о Haskell'e: слишком противоречивы были мысли. И вот, наконец, благодаря этой записи о разборе программки определения двудольности графа я могу это сделать :)

Я понял, что Haskell-программисты — в основном, нужно сказать, хобби-программисты — это те, кто программирует не решение задачи, алгоритм, систему, а Haskell! [1] Посмотрите, какой простой алгоритм описан в заметке, а сколько вокруг него нагромождено языковых конструкций, объяснений и дискуссий. (Чтоб понять, насколько алгоритм прост, можете посмотреть в комментариях варианты на Lisp'е, Python'е).

Мне хорошо знакомо это умонастроение — когда в погоне за максимальным использованием мощи языка забываешь о самой задаче,— поскольку в Lisp-мире оно тоже часто встречается: есть языки, которые способны действительно увлечь. И выражение «это взорвало мне мозг» часто звучат и по поводу Lisp'а, и по поводу Haskell'а. Но это же — фигня! Конечно, не может не радовать узнать что-то новое, но не нужно же радоваться этому, как ребенок новой игрушке. Хороший язык программирования должен быть максимально понятен и прост, должен давать человеку свободу самовыражения. Честно говоря, именно этому я обрадовался, когда открыл для себя Lisp: что нашел то, что искал. А не тому, что увидел какую-то конструкцию или изворот, который не доводилось встречать раньше.

Привет.

Давеча у меня был разговор с моим научным руководителем, Петросяном Леоном Аганесовичем — деканом факультета ПМ-ПУ Санкт-Петербургского Государственного Университета.

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

(2009 год, второе письмо старшего менеджера веб-студии — младшему)
Итак, первоначальные переговоры c клиентом проведены. Смотрим первую часть методички здесь http://habrahabr.ru/blogs/studiobusiness/45543/.
Теперь надо сориентировать клиента по цене. Если он с ней принципиально согласен — переходим к обсуждению Технического задания (ТЗ).
Делаем смету

Selenium

Selenium — это очень удобный (имхо) инструмент для тестирования веб-приложений.

Тесты создаются с помощью дополнения для Firefox, которое может генерировать код теста на различных языках, в том числе и на Python. Затем эти тесты выполняются специальным сервером, Selenium RC.

Сам по себе Selenium не привязан ни к языкам ни к фреймворкам, поэтому чтобы интегрировать его в систему тестирования Django-приложений, нужно приложить очень небольшие усилия.

Для решения задачи интеграции я буду использовать библиотеку Django: Sane Testing. Это библиотека, расширяющая возможности стандартной системы тестирования Django, в том числе и поддержкой тестов Selenium.

В Deadline, Том Демарко пишет о том, что для управления проектом, достаточно управлять его рисками. Действительно, всю работу ПМа можно свести к одному — борьба с рисками, которые могут помешать проекту завершиться в срок, в бюджет и с необходимым уровнем качества. Если, по какой-то причине, рисков в проекте нет, то нет и предмета работы ПМа.

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

Недавно появилась необходимость и желание ознакомится с PyGTK. Литературы на русском по данному вопросу практически нет, а то, что находит гугл в разных блогах — бывает немного устаревшим. Также с удивлением обнаружил, что и на хабре тема PyGTK не особо популярна.

Итак, не буду рассказывать про компоновку элементов интерфейса, ибо такие статьи уже есть. Расскажу про следующий шаг: создание приложения, которое выполняет некую работу, в процессе отображая свой прогресс.

Абстрактные базовые классы и интерфейсы — близкие по назначению и смыслу сущности. Как первые, так и вторые представляют собой своеобразный способ документирования кода и помогают ограничить (decouple) взаимодействие отдельных абстракций в программе (классов).

Питон — очень гибкий язык. Одна из граней этой гибкости — возможности, предоставляемые метапрограммированием. И хотя в ядре языка абстрактные классы и интерфейсы не представлены, первые были реализованы в стандартном модуле abc, вторые — в проекте Zope (модуль zope.interfaces).

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

Разработка, основанная на специфицировании поведения (BDD), — один из краеугольных камней философии Ruby.

Очень удачной реализацией BDD является всем знакомый RSpec. Одной из замечательных черт RSpec является его расширяемость.

Так, мы используем RSpec совместно с Factory Girl (хотя стоило бы перейти на Machinist), RR (прекрасный каркас для заглушек), Spork и недавно перешли с Shoulda на Remarkable.

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

Хорошим способом сделать это является создание нового «ожидателя» (matcher).

Апплет — это небольшое приложение, которое интегрированно в Gnome панель и выполняет какие — либо поэтапные действия. В этой серии постов, я хочу рассказать как создаются эти самые gnome applets, от простого к чему-нибудь к более сложному и интересному. Для создания апплетов мы будем использовать PyGTK, но в принципе писать апплеты для Gnome можно и с помощью связки С + GTK+.

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

Часто приходится разрабатывать приложения для корпоративной системы которые должны были функционировать еще вчера, не требующие строго соответствия корпоративным стандартам. Такими приложениями могут представлять cms к сайтам, gui для сервисов под *nix системы просто приложением учетной системы. Разработка приложений подобного рода на скриптовых языках есть тема! обычно оптимальна с точки зрения скорости выполнения. Под катом пример реализации приложения на python+PyQt4, функции приложения парсинг и загрузка данных из xls файлов…

(От перев. Данная статья не претендует на полноту и непротиворечивость, потому мы не будем строить на ее основании никаких теорий. Это всего лишь практическое пособие для разработчиков, немного исправленное и дополненное мной под реалии Рунета.)

Одним из самых странных статистических фактов, связанных с использованием браузеров, является широкая распространенность Internet Explorer версии 6, 7 и 8. На сегодняшний день все версии Internet Explorer вместе занимают примерно 65% рынка используемых в настоящее время браузеров. Среди веб-разработчиков эта цифра ниже, здесь доля пользователей IE составляет лишь 40% рынка.
(От перев. Надеюсь, эти 40% составляют лишь несчастные верстальщики, проверяющие свои сайты на предмет кроссбраузерности. Статистика по Рунету доступна, например, здесь. Заметьте, в сентябре у всех браузеров IE-семьи график без видимых причин подскочил — это вернулись за свои компьютеры офисные пользователи, самые преданные почитатели наших героев.)

Интересно, что популярность браузеров семейства IE примерно одинакова, нельзя выделить один доменирующий браузер, как это было ранее. (От перев. Конечно, нельзя. Вот смотрю и ну никак не могу выделить доминирующий браузер. =) ) Таким образом, сейчас веб-разработчики обязаны проверять работоспособность своего проекта в различных браузерах, разрабатывая как сайты для своих заказчиков, так и персональные странички.

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

Эта статья является попыткой дать исчерпывающую, легкую в восприятии информацию для веб-разработчиков, пытающихся понять различия в обработке CSS между IE6, IE7 и IE8. Здесь собраны краткие описания для свойств, поддерживаемых одним или двумя браузерами, но не всеми тремя сразу. Здесь не рассматриваются свойства, не выполняемые ни одним из IE, а также специфичные только им. Таким образом, акцент стоит именно на различиях между браузерами, а не на недостатке поддержки ими тех или иных CSS-свойств.

Завтра (3го ноября) в 16-00 буду опять рассказывать широко известный в узких кругах доклад с Highload '2009 под названием «Зачем знать алгоритмы» — про внутреннее устройство СУБД и поисковиков на пальцах.

Посмотреть и послушать можно по адресу firmbook.ru/Catalog/Conference/X03RAmDfHEmwN1A-A1tq9Q — бесплатно и удаленно, такая вот онлайн конференция iCoder.

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

Времени дают два часа, доклад короче, должно остаться время пообщаться о разном. Заходите ;)

Про Vim сказано и написано более чем достаточно. Но большинство материалов представляют собой либо самые первоначальные сведения, либо же советы матерых профессионалов. В результате для того, чтобы приспособить редактор для решения стоящих перед пользователем задач, приходится перелопатить кучу мануалов. Перед осознанием масштаба необходимой работы, нужен нешуточный стимул, чтобы решиться на такое. И вполне может возникнуть резонный вопрос: а зачем мне это? Помимо того, что интересно «пощупать» редактор, о котором столько разговора, должно быть что-то еще?

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

Забегая вперед, скажу, что информацию пришлось собирать фактически по крупицам. Основное направление в использовании Vim в качестве редактора «для программистов» привело к тому, что вопросам обработки «простого» текста уделяется мало внимания. В конце-концов, с поставленной задачей, как мне кажется, удалось справиться.

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

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