twitter2vk — скрипт для автоматической перепубликации статусов из Твиттера во В Контакте. Например, если у вас остались старые друзья, которые никак не хотят уходить из В Контакте.

Преимущества

• Не хранит паролей, так что потеря файла настроек не будет столь страшна. В настройках хранятся только ID сессии В Контакте и данные для OAuth-входа в Твиттер. Особенно актуально для тех, кто использует один пароль для нескольких сервисов.
• Поддерживает ретвиты — публикует во В Контакте статусы других пользователей, которые вы отретвитили.
• Настройка формата статусов и ретвитов во В Контакте. Можно, например, заменять пользователей на ссылки на них или обрезать текст оставляя ссылку после него в полном виде: «Длинный текс… http//twitter.com/my/status/31337».
• Правила исключения статусов. Можно указывать, какие статусы не будут перепубликоваться во В Контакте (например, ответы другим пользователям Твиттера).

Здравствуй хаброчеловек!

Так уж случилось, что с этого семестра в своем вузе я записался на спецкурс по паттернам проектирования. Курс проходит в виде семинаров, на которых ты (студент) должен рассказать чему научился за неделю (имеется ввиду, какие паттерны изучил и применил на практике).

Заместитель генерального директора RuTube, а также экс-руководитель интернет-журналов Elle.ru, MaximOnline.ru, Wday.ru Владимир Барабанов рассказывает о глянцевой прессе в Рунете, анализирует сложившуюся ситуацию на рынке видеохостингов, делится планами RuTube на ближайшее будущее, а также предлагает президенту РФ достойное занятие на выходных.

Интервью с гостем:

• Издательские дома и Рунет
• YouTube и RuTube: в чем разница между «Ю» и «Ру»?
• UGC vs. профессиональный контент: кто победит?
• RuTube и прибыль
• Газпром – идеальный руководитель?
• Ждет ли «Вконтакте» судьба «Ли.ру»?

Обсуждаемые события:

• Русский Forbes заинтересован в аудитории Facebook и Linkedin
• TNS подсчитал пользователей Рунета
• «Яндекс» предлагает потестировать «Снежинск»
• Клоны рейтинга блогов «Яндекса»
• «Вымпелком» намерен развивать «Апорт»
• В Рунете набралось около 15 млн. сайтов

_{Послушать предыдущие выпуски и подписаться на RSS подкаста
Страница «Рунетологии» на Facebook}

Для начала определимся с понятиями:
RubyGems — фрэймворк для установки и запаковки Ruby библиотек и приложений.
gem — пакет(файл) с библиотекой или приложением. Имеет стандартизированный вид и расположен в хранилище в сети.
gem command tool — RubyGems предоставляет утилиту «gem» для работы с gem пакетами из командной строки. Она интегрирована с Ruby и позволяет получать доступ к установленным gem'ам как к библиотекам.

В чем же предназначение RubyGems?

До того как появилась RubyGems, для установки новой библиотеки нужно было найти, скачать её, попытаться установить, часто лишь для того, чтобы убедиться в отсутствии нужных зависимостей. Если же библиотека запакована с помощью RubyGems, достаточно попросить RubyGems сделать это за нас и получить установленную, интегрированную библиотеку со всеми нужными зависимостями. В дополнение ко всему утилита gem — платформонезависима, неважно какую ОС вы используете, везде механизм установки библиотек и приложений будет одинаков. Здорово, правда?

Под катом будут описаны:
1) Поиск, получение деталей, установка gem's
2) Доступ документации по установленному gem
3) Использование установленных gem's
4) Работа с версиями gem's
5) Создание собственных gem's

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

Последние релизы MRI Ruby показывают значительное замедление при подключении файлов.

Например, наше средненькое рельсовое приложение при загрузке делает require около 2200 раз — это где-то совсем в правой части графика. Совсем никуда не годится. На 1.9.2 приложение стартует за 20 секунд, а на 1.9.3 уже 46. Слишком медленно!

Все началось с ...

Несколько лет назад я только начал знакомиться с web-программированием, и одним из моих первых «проектов» был каталожек сайтов. Разработка велась для себя, в целях повышения опыта. Но т.к. аналогичных сайтов тьма-тьмущая, хотелось сделать что-то особенное. Я решил, что каждый сайт в каталоге будет представлен со скриншотом. Как все это автоматизировать я не знал, потому первое время я делал все скриншоты руками и заливал их уже как готовые файлы.

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

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

Итого, я решил сделать собственный «велосипед».

Расскажу как в Ruby работает такая элегантная конструкция:

User.all.map &:name           # получить массив имен пользователей

вместо

User.all.map { |user| user.name }

Сначала кажется что это свойство перечисляемых классов, но на самом деле это не так.

В качестве предисловия к переводу. Открываем Firefox/Opera, переходим по ссылке, смотрим исходный код страницы и удивляемся. Потому что его нет. Под катом рассказ, как такое можно сделать.

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

Так как большинство авторов не удосуживается хотя бы залезть в документацию, то обычно в таких статьях вся информация базируется на неких слухах и пересказах слухов. Эти слухи бродят по сети и поражают википедию, хабрахабр и другие уважаемые ресурсы. В результате получаются опусы вроде "Вы наверное шутите, мистер Дал, или почему Node.js" (пунктуация автора сохранена): она, в основном, верная по сути, но изобилует неточностями, содержит ряд фактических ошибок и изображает предмет с какого-то непонятного ракурса.

Мне было сложно пройти мимо статьи, изобилующей фразами вроде «эффективные реализации polling'а на сегодняшний день имеются лишь в *nix-системах» (как будто poll() есть где-то, кроме некоторых *nix). Этот пост начинался как комментарий, разъясняющий уважаемому inikulin ошибки в его статье. В процессе написания оказалось, что проще изложить предмет с самого начала, что я собственно и делаю отдельным постом.
В моем очерке нет срыва покровов или каких-то неизвестных трюков, здесь просто описываются преимущества и недостатки разных подходов человеком, который проверял, как всё это работает на практике в разных операционных системах.
Для желающих просветиться — добро пожаловать под кат.

Node.js — вещь, вокруг которой сейчас много шума, восторженных отзывов и гневливых выкриков. При этом, по моим наблюдениям, в умах людей закрепилось следующее представление о том что же такое Node.js: «это штука, позволяющая писать на JavaScript на серверной стороне и использующая JavaScript-движок от Google Chrome». Поклонники языка восторженно вздохнули: «Ах! Сбылось!», противники же процедили сквозь зубы: «Ну вот только еще этой ерунды с прототипами и динамической типизацией нам на серверах не хватало!». И дружно побежали ломать копья в блоги и форумы.

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

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

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

Мы делили апельсин, много нас, а он один

В американской традиции стартапов принято брать в долю всех участников проекта, работающих с первого дня его основания. Отличный способ мотивации команды, скажу я вам. Но как делить баснословные доходы, если они таки будут? Самое первое, приходящее на ум — поделить поровну. Таким образом, если над стартапом работало пять человек, то каждому достанется по 20%. Справедливо? Не очень.

У американцев есть отличная поговорка про курицу и свинью «a chicken is involved with breakfast, but a pig is committed»: речь о яичнице с беконом на завтрак, для приготовления которого требуется некоторое усилие от курицы (снести яйцо и жить себе спокойно дальше), в то время как свинье придётся принести куда более существенную жертву. Так же и в бизнесе: некоторые участники проекта выполняют работу достаточно формально и потом наблюдают за результатами, другие же несут принципиально большие риски и вкладываются в дело сильнее.

Frank Demmler, профессор предпринимательства в бизнес-школе при Carnegie Mellon University, предложил следующий метод распределения долей в стартапе.

Samy Mamkar разработал систему, которая позволяет хранить куки в 8 местах, автоматически восстанавливая друг друга, и даже добиться того, чтобы куки, поставленное в одном браузере, действовало и в другом.

Удалить это куки практически невозможно! (Все возможно, конечно, но слишком много мороки)

Куки хранятся в:

• HTTP Cookies;
• Local Shared Objects (Flash);
• Сохранение куки в значениях RGB автосгенерированных и форсированно кэшированных PNG с использованием HTML5 canvas;
• Сохранение куки в Web History;
• HTML5 Session Storage;
• HTML5 Local Storage;
• HTML5 Global Storage;
• HTML5 Database Storage через SQLite.

При удалении из одного из этих мест кука автоматически восстанавливается из оставшихся. Работает даже если пользователь сменит браузер (через Local Shared Objects из Flash).

Описание (на английском) и демо: http://samy.pl/evercookie/.
Попробуйте удалить куки, почистить систему и зайти назад.



Как пользоваться?

Предыстория

Я занимаюсь разработкой IFrame приложений для социальной сети ВКонтакте. Самый удобный способ навигации по приложению — это динамическая подгрузка данных, без перезагрузки всей страницы. Раньше я генерил html код который нужно отобразить на сервере, пока не встретил EJS — JavaScript Templates…

EJS — Embedded JavaScript

EJS оказался одним из самых удобных и подходящих мне шаблонизаторов. Он работает, как с одиночными переменными, так и с массивами (читай объектами), присутствует логика (if...else...).

Node.js обычно вызывал у людей, которым я о нём рассказывал, две различные реакции. В основном они воспринимали его «как есть», однако многие были сбиты с толку.

Если вы относитесь ко второй группе, я попробую объяснить, что же такое Node.js:

• Это инструмент командной строки. Вы скачиваете архив, компилируете и устанавливаете его.
• Это позволит вам выполнять программы на JavaScript, набрав 'node my_app.js' в терминале.
• JavaScript выполняется движком V8 (тем самым, благодаря которому так быстро работает Google Chrome).
• Node.js предоставляет API для доступа к сети и файловой системе из JavaScript.

1 Введение

В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.

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

Это перевод статьи, датированной 1м сентября 2009 года, следует это учесть при прочтении. — прим. пер.

В последний месяц или два команда инженеров Digg потратила совсем немного времени на изучение, тестирование и окончательное внедрение Cassandra в продакшен. Это был очень веcёлый проект, но до того, как веселье началось, нам пришлось потратить какое-то время на выяснение того, что же представляет собой модель данных Cassandra… фраза «WTF is a «super column»» («что за фигня этот суперстолбец?») была произнесена не один раз.

Если вы работали ранее с РСУБД (это касается почти всех), вы вероятно будете немного обескуражены некоторыми названиями при изучении модели данных Cassandra. Мне и моей команде в Digg потребовалось несколько дней обсуждений, прежде чем мы «врубились». Пару недель назад в списке рассылки разработчиков шёл процесс bikeshed-а на тему полностью новой схемы именования для разрешения неразберихи. На всём протяжении дискуссии я думал: «может, если будет несколько нормальных примеров, люди не будут так смущены названиями». Так, это моя попытка объяснения модели данных Cassandra; она предназначена для того, чтобы вы ознакомились, но не уходили в дебри, и, надеюсь, это поможет прояснить некоторые вещи.

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

Сегодня наткнулся довольно занятный gist на github'е.

Большинство разработчиков на MySQL знакомы с командой EXPLAIN, однако значительно меньше людей знают о команде EXPLAIN EXTENDED, появившуюся ещё в MySQL 4.1, и ещё меньше умеют ею пользоваться.

EXPLAIN EXTENDED умеет показывать, что же конкретно делает с Вашим запросом оптимизатор MySQL. Для разработчика может быть совсем не очевидно, насколько сильно может отличаться написанный им запрос от того, который в действительности будет выполнен сервером. Этот процесс называется механизмом перезаписи запросов (query-rewrite), и он является частью любого хорошего SQL-оптимизатора. Команда EXPLAIN EXTENDED добавляет дополнительные предупреждения (warnings) к выводу команды EXPLAIN, в том числе и переписанный SQL-запрос.