Потребовалось мне как-то запустить игру, которая запускается под wine, через прокси. Поднял ssh-туннель, запустил игру через proxychains, и… игра не смогла соединиться с сервером, хотя chromium без проблем работал и показывал ip прокси. Попробовал tsocks — игра вообще не запустилась. Можно, конечно, было настроить VPN-туннель с помощью того же ssh, но сервер — VPS, под OpenVZ, у которого по умолчанию выключен TUN, что привело бы к письму в техподдержку и ожиданию.
Итак, пятиминутное гугление привело меня к заброшенному проекту Transocks, который, в отличие от proxychains и tsocks, которые подгружают свои библиотеки и перехватывают сетевые вызовы, слушает определенный порт и перенаправляет все, что в него пришло, через socks4 прокси. К сожалению, transocks у меня не собрался, и я начал гуглить дальше.

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

Частично содержание данной статьи пересекается со статьей Валерии Маллаевой О fla-исходниках.

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

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

Устанавливал я Ubuntu 10.10 на ноутбук Acer Aspire Timeline 5810TG. Эта машина обладает экраном в почти 16 дюймов и относительно производительным железом, зато батарея достаточно емкая, чтобы ставить с ней личные рекорды.

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

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

Договоры, отчеты, акты — кому охота заниматься этой скукотой, когда вокруг бьет ключом и фонтанирует идеями креативная жизнь? Особенно, если заказчик снисходительно хлопает творческого подрядчика по плечу: «Да ладно, зачем какие-то договоры. Мое слово — закон!» Остается только радостно согласиться и приступить к работе.

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

Архитектура и платформа проекта Одноклассники

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

Про bash completion на хабре я уже писал тут, и даже конце пообещал рассказать про настройку автодополнения для собственных скриптов.

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

В 2002 году Марк Ньюхаус (Mark Newhouse) опубликовал статью «Укрощение списков» ("Taming Lists"), довольно-таки интересную часть которой он посвятил объяснению того, как создавать собственные списки, украшенные псевдо-элементами. Почти десять лет спустя Николас Галлахер (Nicolas Gallagher) изобрел технику, которая использует псевдо-элементы из спрайтов, для создания фоновых изображений.
Сегондя, основываясь на опыте гигантов, мы постараемся развить эту тему. Мы обсудим, как можно украсить элементы без дополнительной разметки, используя только технику CSS-спрайтов. Результат будет работать также в Internet Explorer 6 и 7 версии.

В предыдущей статье был описан метод перехвата вызовов для разделяемых библиотек ELF. А сейчас мы посмотрим как сделать то же самое с библиотеками в формате Mach-O.

Вкратце напомню ситуацию. Имеем программу под Mac OS X, которая пользуется множеством сторонних динамически-компонуемых библиотек, которые, в свою очередь, также пользуются функциями друг друга.

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

Как обычно, нетерпеливые могут все скачать и попробовать прямо сейчас.

Под катом описан пример конфигурации связки mercurial+nginx и приведен скрипт автоматизации всего вышеперечисленного.

Топик — вольный перевод статьи Vim Plugins You Should Know About, Part I: surround.vim Петериса Круминса.

UPD: вторая часть

Что такое плагин surround.vim? Вот что говорит о нем автор, Тим Поп (Tim Pope):

Surround.vim работает со всем, что «окружает»: скобками, кавычками, тегами XML и т.п. Плагин предоставляет сочетания клавиш, которыми можно легко удалять, изменять и добавлять пары таких окружающих элементов.

DSL (Domain Specific Languages) — языки, специфичные для решения задач какой-либо предметной области (в противовес языкам общего назначения типа Java или C#). Более подробное описание и примеры есть на википедии, я же хочу написать про то, как довольно легко встроить в приложение (C#) свой собственный DSL на базе языка Boo.

Фреймворк Cappuccino – уникальная технология, позволяющая создавать веб-приложения десктопного качества. Он абстрагирует DOM и вместо него предоставляет Cocoa-подобный API. Вместо того, чтобы возиться с CSS-версткой и кроссбраузерными проблемами, вы используете интерфейсы, специально созданные для разработки приложений, а не статических страниц, интерфейсы, взятые с платформ Mac OS X и iOS.

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

Друзья, представляю вам перевод статьи «The 7 deadly sins of software development» автора Neil McAllister, опубликованной на infoworld.com.

Я так подозреваю, что очень многие разработчики софта для iPhone/iPad будут просто счастливы прочитать этот пост.
Я уже давненько пользуюсь гаджетами фирмы Apple и регулярно просматриваю тематические ресурсы на предмет обзоров разных приложений. И если честно, меня очень раздражают видео-обзоры, которые сделаны не очень качественной камерой и явно видно, что деланы непрофессионально.
Конечно, когда бюджет разработки невелик, то вписать в статью затрат качественный видео ролик – это роскошь. Сегодня я расскажу, как сделать качественный видеоролик-презентацию приложения для айДевайсов.

Парадигмы программирования

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

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

• инструкция (императивное программирование, FORTRAN/C/PHP),
• функция (функциональное программирование, Haskell/Lisp/F#/Scala),
• прототип (прототипное программирование, JavaScript),
• объект (объектно-ориентированное программирование, С++/Java),
• факт (логическое программирование, PROLOG).

Стоит заметить, что в общем случае язык программирования однозначно не определяет используемую парадигму: на том же PHP можно писать как императивные, так и объектно-ориентированные программы.

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

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

Большинство примеров кода не привязаны к какому-либо конкретному языку программирования, но для наглядности я буду использовать PHP.

Итак, поехали.

Иногда случается, что стройную и продуманную систему юнит-тестов душит сильная связность компонентов — особенно этим грешит legacy код, изначально не предназначенный для тестирования. Рефакторинг, конечно, спасает — но не всегда можно рефакторить. Одной из проблем, возникающих при создании юнит-тестов может стать использование static методов или non-virtual методов, которые должны быть перегружены для успешного написания тестов. Поможет в этом проект от Microsoft Research — Moles.

Представляем вашему вниманию доклад Максима Лапшина, сделанный им на конференции Application Developer Days. Мы собрали воедино видео и аудио, слайды презентации, а также стенограмму доклада. Последнее потребовало огромных усилий, но оно явно того стоит. Сорокаминутный доклад можно «услышать» в несколько раз быстрее.

Свел видео и презентацию в единый ролик, а также записал стенограмму Стас Фомин (человек и пароход локомотив :)).

У нас в компании с незапамятных времен существует гласно-негласное правило о логировании входа в каждую функцию. И ладно бы это ограничивалось простой строчкой Logger.LogEntering() в их начале (хотя, наверное, тоже надоело бы), так еще и наш «замечательный» доморощенный логгер получать названия функций из которых он вызван не умеет, и как следствие, эта единственная строчка разрасталась до эпического Logger.Log(«Classname.FunctionName — Entering») or something like that.

Неудивительно, что под воздействием недавних топиков о Mono.Cecil и родилась задача автоматизации процесса.