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

Мотивация

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

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

Во всяком случае, это только первый черновик стандарта, который я предлагаю. Комментарии приветствуются!

Знаете, я ж могу нажать её.
Не просто нажать, я могу нажать в самый неподходящий момент. Я могу нажать её в середине процесса копирования большого файла, сразу после того, как запустится второй поток.

или простой способ создания консистентныx резервныx копий без остановки сервера с помощью клонирования виртуальных машин

Идеальный бэкап в вакууме

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

Грубая реальность вносит коррективы: если при настройке копирования не предусмотреть множество мелочей, то при восстановлении может случиться так, что часть данных в бэкапе окажется повреждена непонятным образом. Легкое восстановление превратится в мучительные поиски кусочков в разных архивах и собирание из них одного целого. Уход в закат откладывается из-за нарушенной консистентности копии.

Всем привет!

Я активный пользователь open-source фрэймворка Grab (itforge уже писал о нем здесь и здесь) и 1/2 проекта GrabLab (который занимается собственно коммерческой эксплуатацией фрэймворка). Т.к. парсим сайты мы часто, помногу и задания как правило совершенно не похожи друг на друга, хотелось бы поделится своим опытом в вопросе построения типичного парсинг проекта.

Немного про инструментарий который помогает мне в работе

В качестве рабочего браузера я использую FireFox с плагинами HttpFox (анализировать входящий/исходящий http трафик), XPather (позволяет проверять xpath выражения), SQLite Manager (просмотр sqlite таблиц), код набираю в emacs, где активно использую сниппеты (YASnippets) для часто встречающихся конструкций.

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

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

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

Почему сайты размещают столь многословные ToS — понятно. Фактически, это юридический документ, который составляют юристы для юристов, а у тех в профессиональной среде принято использовать именно такой язык, нельзя упрощать формулировки.

Любопытный выход из положения предложил фотосайт 500px.com — их пользовательское соглашение составлено в двух вариантах. В левой колонке оригинальный текст, имеющий юридическую силу. А в правой колонке смысл каждого пункта изложен в двух словах. Кстати, таким же образом изложена и политика приватности 500px. Пожалуй, это хорошая идея.

Доброго времени суток!
Давно искал инструмент, чтобы быстро можно было узнать принадлежность того или иного телефонного номера к тому или иному оператору связи и/или региону.

Всегда использовал для этих задач МТТ, чего, в принципе всегда хватало.
Но хотелось чего-то ещё более простого и быстрого.

Если Вас также как и меня интересовало что-то подобное, прошу под кат.

Недавно Яндекс анонсировал свой новый сервис, подобный DropBox'у. Многие его сразу же начали поливать из ведра, хотя, я думаю, зря.

Один из плюсов лично для меня, линуксоида — не нужно устанавливать дополнительные приложения, как в случае с DropBox'ом. Сервис можно подключить через файловый менеджер Nautilus, используя WebDAV. Что я, собственно, сразу же и сделал.

Однако, я не стал на этом ограничиваться, ведь гуёвый доступ — не совсем хорошо, консольки никто не отменял.

Qt5 alpha увидел свет. В этой статье я опишу одну из фич, над которыми работал — это новый синтаксис сигналов и слотов.

Предыдущий синтаксис

Вот как мы обычно соединяем сигнал и слот:

connect(sender, SIGNAL(valueChanged(QString,QString)),
        receiver, SLOT(updateValue(QString)) );

На самом деле макросы SIGNAL and SLOT преобразуют свои аргументы в строки. Затем QObject::connect() сравнит эти строки с данными интроспекции собранными утилитой moc.

В чем проблема этого синтаксиса?

Не смотря на то, что в целом все работает хорошо, некоторые неудобства все же есть:

Эта статья открывает серию статей — если окажется, что Хабраколлеги сочтут ее интересной, ибо первое правило публичных выступлений гласит: рассказывай людям о том, что им интересно!

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

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

Историческая справка: на Хабре по этой теме уже было небольшое обсуждение год назад.

Вступление 1.

Много думал и анализировал информацию на тему разработки игр. И чтобы не потерять, а так же поделиться с людьми, получить подсказки, советы и комментарии — решил оформить и выложить статью. На сегодняшний день “геймдизайн” все больше обретает очертания некой науки, требующей особого подхода и изучения. К сожалению, в общем доступе находится очень мало структурированной информации. Что касается иностранных авторов, имеющих большой опыт и ряд успешных проектов — зачастую их труды так и не попадают на прилавки отечественных магазинов. А изучить их в оригинале многим мешает языковой барьер.
В данной ситуации спасением служат статьи, где люди делятся впечатлениям и личным опытом по разработке игр. Эти статьи не только и не столько доносят до читателей новую информацию, сколько подают ее в новом свете, позволяя более четко осознать и отобразить в жизнь.

Вступление 2

Хочу отметить, что на написание материала оказало влияние выступление на Sociality Rocks 2011 Henric Suuronen — руководитель студии Wooga, разработчика Bubble Island и других хитов. Особого внимания заслуживает статья Андрея Плахова “Геймдизайнерам о программистах или как программировать программистов”. По аналогии с той статьей возникла мысль, что программировать можно и пользователей тоже. Программировать их модель поведения, чтобы их развлекать и извлекать нужные нам ценности — платежи, удержание в игре, привлечение новых игроков. И одним из инструментов удержания служит набор функций в приложении, который можно условно назвать игровым циклом. Об этом мы и поговорим далее

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

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

Именно так выглядит Data Mining в клиентской аналитике. И именно так это уже работает на практике в сотнях крупных компаний по всему миру и в нашей стране.

Для создания переносимых многопоточных приложений предлагаю воспользоваться библиотекой Glib.
Glib — это достаточно большая кросс-платформенная библиотека, которая, кроме потоков, включает в себя поддержку интернационализации, работу со строками, массивами, файлами, таймерами, и много чего другого, вплоть до XML парсера и поддерки .ini конфигурационных файлов.
В тоже время эта библиотека достаточно маленькая и почти не имеет зависимостей, что позволяет без особых проблем включать её в Windows-проекты, а в unix-подобных системах Glib уже есть.

Вступление

Уже около двух лет я участвую в OpenSource проекте SourceAnalyzer, и вот появилась необходимость написать парсер для языка Python, который должен уметь строить граф вызовов (Call Graph) и граф зависимостей классов (Class Graph Dependency). Если точнее, граф строится с помощью других инструментов, а парсер должен лишь подготовить для этих инструментов данные.

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

С технической точки зрения юнит-тесты – это очень простой инструмент, основанный на паре несложных концепций: (1) тестируемый класс, (2) набор тестовых методов, завернутых в некоторый класс и (3) набор методов, с помощью которых можно удостовериться в том, что состояние тестового класса соответствует (или не соответствует) некоторому значению.

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach"), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.

Доброго времени суток!



В полку Open Source прибыло! Мы (@kulakowka, k12th, dhomich и я) рады представить вашему вниманию перевод официальной документации по Backbone.JS — каркасу для создания RIA приложений на JavaScript, автором которого является Jeremy Askenas — создатель CoffeeScript.

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



Поиграть в игру можно здесь (для работы нужна Java, есть сообщения что под FF не запускается).

Продолжение вот этой статьи habrahabr.ru/post/131212, где я собирался показать, как «и ошибки удобно обрабатывать и exceptions при этом не использовать», да всё руки не доходили.

Итак, будем считать, что у нас ситуация, что «настоящие C++ exceptions» использовать нельзя — например, языком разработки является C или компилятор С++ для нашей платформы не поддерживает exceptions (или формально поддерживает, а реально этим пользоваться нельзя). Это, конечно, нетипично для desktop приложений, но вполне обычно для embedded разработки.

Он посинел, ему плохо?

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

Среда ядра накладывает множество ограничений на свободу действий программиста: учитывай IRQL, синхронизируй доступ к разделяемым переменным, не задерживайся в ISR, проверяй любые данные из «юзерленда»… Нарушив хотя бы одно из правил, вы получите настоящий выговор из штампованных фраз в стандартном VGA-видеорежиме с худой палитрой.