Честное слово, это почти случайно получилось, что такая новость пришла к началу апреля и Дню космонавтики. Сегодня я расскажу о том, как история, которая началась и оборвалась более 40 лет назад, внезапно получила продолжение в наши дни. О том, как простой юзернейм вконтакта, в своем интересе к Марсу дошел до NASA. О том, что международная солидарность ученых — не пустой звук. И о том, что космос ближе, чем кажется.

Мы искали Марс-3.

И мы нашли его! Прямо на Марсе, на дне гигантского кратера Птолемея, среди безжизненных пустошей и валунов.

О том, как мы это сделали, сегодняшний рассказ.

10 PRINT CHR$(205.5+RND(1)); : GOTO 10 — это название книги, выпущенной издательством MIT press, авторы которой исследуют историю, эстетику и философию программирования, основываясь на одной-единственной крошечной однострочной программе на Бейсике для компьютера Commodore 64, которая генерирует похожий на лабиринт бесконечный узор. Собственно, заголовок книги — её полный листинг. Эта коротенькая демка была популярна тридцать лет назад и портировалась на множество языков и платформ.

Поскольку побеждать Великий Китайский Роскомнадзор наша штука для обхода блокировок в интернете пока не особенно научилась, а рассказать что-нибудь странное про свою работу все равно хочется, расскажу про реимплементацию похожего на Readability алгоритма при помощи Node.js и Бэйцзинского технологического института.

Что это вообще такое

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

Лирическое отступление про парсеры

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

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

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

Ну а чтобы не быть голословным — перейдём к примерам. Нас ждут:

1. Неудаляемые модели, которые мы удалим
2. Валидируемые поля, которые не валидируются
3. Два админа, которые портят данные

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

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

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

В качестве shell-оболочки рассмотрим bash, как самую используемую. А в качестве операции над файлами рассмотрим удаление, как самую деструктивную.

В процессе работы с операционными системами GNU/Linux обычно привыкаешь делать какие-то операции одними и теми же средствами. Философия UNIX (*nix-way) предполагает наличие большого количества простых программ для выполнения простых действий, а результаты работы можно передавать между разными программами через потоки. Но вот представьте, что возникает ситуация, когда кто-то нечаянно, по глупости или из нехороших побуждений удалил исполнимый файл, который являлся бинарным файлом какой-то команды, которой вы более или менее часто пользовались. И что тогда делать?

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

Оригинал статьи: smyck.net/2012/04/22/why-erlang

Шансы, что вы читаете эту статью на устройстве с многоядерным процесcором, растут каждый день, вот почему все постоянно говорят про параллелизм (concurrency). Параллелизм для наших web приложений и API бэкендов, это когда вывод htop выглядит примерно как на картинке:



Я недавно был на великолепной Ruby конференции и три или четыре доклада были про параллелизм. Сообщество Ruby достаточно открыто и обсуждалось достаточно много возможностей: использовать потоки, использовать различные среды выполнения Ruby, чтобы обойти GIL, использовать больше процессоров, использовать модель акторов через библиотеки как Celluloid или даже использовать Akka через JRuby.

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

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

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

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

Формально, циклические ссылки нельзя назвать утечками: сборка мусора рано или поздно уничтожит такие объекты. Беда только в том, что Питон не может сам определить, когда еще рано, а когда уже поздно. В моем случае система просто прибивала процесс с Питоном, если сборка мусора не начиналась вовремя.

Здравствуйте, господа!

Я был достаточно приятно удивлен, когда узнал, что проект Ajax.org, именуемый Ace почти ни разу не упоминался на хабре. Ace — это веб-редактор исходного кода нового поколения. Он поддерживает уйму различных функций, среди которых: наличие режимов подсветки синтаксиса для более чем 60 языков программирования, поддержка сумашедшего количества цветовых схем из различных популярных IDE, функций, среди которых: широкая кастомизация, проверка синтаксиса для нескольких скриптовых языков. Так уж получилось, что эта статья скорее всего будет разносторонняя, т.е. содержать материал для веб-разработчиков и С++ программистов, которых я так успешно агитирую в сторону Qt. Итак, что вы можете прочитать в этой статье?

• Быстрый старт с Ace. Где я могу использовать Ace? Почему?
• Портирование Ace на Qt и обертка его API: How-To для создателей Qt5-based библиотек (таких как мой порт Ace — Novile

Сейчас позволю себе показать пару скриншотов example-приложения, которое использует мою библиотеку Novile:

Vim — уникальный по своей гибкости редактор, который при должной настройке может едва ли не идеально удовлетворять все пожелания работающего с ним. Правда эта настройка может продолжаться месяцы, а то и годы, что является и достоинством, и недостатком vim’а. Существует множество статей и туториалов по использованию Vim для разработки на Python и Django, надеюсь мне удастся рассказать что-то новое. В своей статье я постараюсь по минимуму упоминать плагины общего назначения, вроде NERDTree или surround.vim и опишу несколько более специализированных расширений и настроек, которые существенно упростили процесс работы на Python.

Это статья о том, как был сделан демонстрационный пример Wall Clock in Pure CSS3. Изначально, я предполагал написать данную статью в виде пошагового учебного пособия, но в процессе я понял, что такой пример мало для этого подходит. Потому я решил остановиться только на деталях, которые, на мой взгляд, наиболее интересны, а реализацию остального можно посмотреть и в коде.

Для начала собственно сам пример — на codepen.io или на cssdesk.сom

От переводчика:
Многие знают, что ffmpeg — это сила, но не все знают, какая именно. Он многогранен и безграничен, а его man объёмен и местами малопонятен, лишь немногие постигли дао профессиональной работы с ним. И тем не менее, этот инструмент может быть полезен почти всем, кто хоть иногда работает с видео и звуком, даже на бытовом уровне. О некоторых полезных консольных командах ffmpeg и пойдёт речь в статье. В некоторых местах я взял на себя смелость вставить ссылки на поясняющие статьи.

ffmpeg — это кроссплатформенная open-source библиотека для обработки видео- и аудиофайлов. Я собрал 19 полезных и удивительных команд, покрывающих почти все нужды: конвертация видео, извлечение звуковой дорожки, конвертирование для iPod или PSP, и многое другое.

1. Получение информации о видеофайле

ffmpeg -i video.avi

2. Превратить набор картинок в видео

ffmpeg -f image2 -i image%d.jpg video.mpg

Эта команда преобразует все картинки из текущей директории (названные image1.jpg, image2.jpg и т.д.) в видеофайл video.mpg

(примечание переводчика: мне больше нравится такой формат:

ffmpeg -r 12 -y -i "image_%010d.png" output.mpg

здесь задаётся frame rate (12) для видео, формат «image_%010d.png» означает, что картинки будут искаться в виде image_0000000001.png, image_0000000002.png и тд, то есть, в формате printf)

Техника – это способ справиться с заданием, и у нас, разработчиков и дизайнеров фронтэнда, этих способов бывает достаточно много. При это, будучи погруженными в рутинную работу, мы порой не всегда замечаем как стремительно меняется окружающая нас сфера. В период с 2002 по 2010 годы сообщество фронтэнд-разработчиков буквально покрывалось язвами избыточного кода и ресурсов, от которых страдали и работа сайтов, и удобство их использования. Чтобы с этим справиться, мы придумали уйму хаков, трюков и уловок под кодовым названием «техника». Мы по-прежнему продолжаем выполнять поставленные перед нами задания, просто используем не самые эффективные способы.



Оборачиваясь назад, отметим, что в последние несколько лет установились новые, лучшие, стандарты и способы их применения, позволяя нам создавать более продвинутые «техники». Этот новый мир, открытый перед нами, называется «modern web». Web 2.0, которым восхищались в свое время, сегодня для нас стал запутанным и застойным. С одной стороны нет сомнений в том, что подобная судьба постигнет и то, что мы называем «modern web». С другой — пока что мы можем использовать этот термин и злоупотреблять им сколько угодно, пока понимаем, что он означает.



В 2010 появился стандарт HTML5, обеспечивающий совершенно новую, полустандартизованную веб-среду. Такие браузеры, как Opera, Firefox, Chrome и Safari приняли нововведения, и их разработчики вышли за пределы реализации стандартов и изучения интерфейса программирования приложений. Чтобы представить себе, насколько автономны эти браузеры, можно ознакомиться с отличной наглядной демонстрацией поддержки HTML5 на www.html5readiness.com.

Сегодня команда Twitter представила общественности собственный фреймворк. Flight — это легкий компонентный javascript фреймворк, каждый компонент которого описывает поведение элементов на странице. На самом деле, вы скорее всего уже видели Flight в действии, потому что Twitter использует его для своих приложений. Вы можете посмотреть демонстрацию возможностей фреймворка в виде простейшего почтового клиента (код на github).

Новый фреймворк использует ES5-Shim для поддержки ES5 в старых браузерах и jQuery для манипуляции DOM. Также потребуется одна из реализаций AMD, например require.js или loadrunner.

Version: 0.2

Возникла у меня потребность атомарного обновления в реальном времени страницы у некоторого количества пользователей в зависимости от действий других пользователей (не гербалайф чат). Понятное дело, можно всё выкинуть в помойку и, по-молодецки, запилить с нуля на tornado/twisted.web, но явно не самый продуктивный путь (да и я не мо́лодец ни разу) когда всё что надо — уже работает на Django и нужно всего-то чуть-чуть… Естественным образом, по сути своей, сюда просится WebSocket. И всё бы ничего но Django WSGI приложение, а этот стандарт не предполагает таких выкрутасов даже близко (пока). Гугления интернетов навели, в очередной раз, на труд известного python-гуру kmike (это без сарказма, т.к. его работы выручали меня лично уже не однократно, за что нижайший ему поклон!).

Итак если вы хотите скрестить ваш Django проект с websocket посредством js библиотеки socket.io или sockjs — вилькоммен!

Каждый из нас выбирает для себя наиболее удобную среду разработки. Многие пользуются отдельной IDE, несколькими открытыми консолями, отдельным браузером, множеством прочих сторонних инструментов. Я же придерживаюсь принципа — все должно быть милимастично и просто конфигурируемо. Tmux позволяет сделать очень удобную рабочую среду для программиста.


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

Онлайн-сервисы становятся все популярнее, постепенно усложняя функционал и улучшая интерфейсы. В этой подборке представлены онлайн-инструменты для кодеров.

Cloud9

«Это Google Docs, только для кода» — так говорят о проекте. Облачный сервис вырос из Mozilla Bespin. Основные фишки: SSH, drag-and-drop и возможность разработки оффлайн.

Дариус Каземи (Darius Kazemi), программист из США решил разнообразить свою жизнь подарками… самому себе. Но поскольку в данном случае теряется изюминка в виде сюрприза от неизвестного подарка, он решил купить подарки при помощи самописного скрипта, назвав его Amazon Random Shopper.

Pudb — полноэкранный консольный дебагер с графическим интерфейсом. Большим плюсом является то, что в нем есть подсветка синтаксиса, дополнительные панели вывода информации, горячии клавиши и интерграция с IPython.

pdb, в сравнении с Pubd, показался жутно не удобным и ограниченым. Поиск ошибок стал занимать на много меньше времени и приносить больше удовольствия. При первом взгляде на него вспоминался Assembler и Turbo Pascal в студенческие годы в техникуме.

Если кто заинтересовался примеры установки и использования под катом.