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

Встречайте, Vector Damage. Полноценный (ну, почти) 3D шутер на осциллографе.

Современный веб лучше всего характеризирует термин “социальный”. В отличие от веба блогерского (веба 2004-2006) веб социальный привлек больше пользователей. Он проще и доступнее, не требует от пользователя особенных мысленных изысков, а только наличия времени, которое можно убивать в Сети. Конечно, я утрирую – кому-то – убивать, кому-то – работать. Кто-то использует социалки для развлечения и времяпрепровождения, кто-то – чтобы быть на связи, быть известным своим коллегам и прочих важных вещей для своей работы.

У веба социального есть свои недостатки – онлайновая активность в той или иной мере выставляет жизнь пользователя на показ, делает ее не личной, а публичной. На Одноклассниках мы вешаем свои фото, в Моем круге рассказываем, когда начали искать работу, на ВКонтакте подробно описываем свои предпочтения, в ЖЖ и на Фотках.Яндекс размещаем фото себя и близких и рассказываем о повседневных делах. Сейчас все это можно сделать еще проще в Twitter-е.

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

Однако я уже не один раз наблюдала у людей изменение своего онлайнового поведения. Которое я назвала пост-социальным синдромом восприятия веба. Он наступает тогда, когда человек вовсю “наелся” онлайновой социальности и сворачивает ее до необходимого минимума. Перестает обновлять ЖЖ, сворачивает активность в других социальных сетях, в профессиональных, правда, эта активность сохраняется на уровне необходимой, равно как и активность профессионального блога. Но не более. Излишняя активность онлайновой жизни, утомив и доказав свою суррогатность, сводится на “нет”, точнее – доводится до нужного уровня.

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

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

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

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

Мнение переводчика может иногда не совпадать с мнением автора, но переводить статью было крайне занимательно.

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

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

Мотивация

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

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

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

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

Причины для замены коневой ФС бывают разные:

• перевод / в LVM
• перевод / в mdraid
• замена типа файловой системы (ext3 => btrfs)
• уменьшение размера ФС (resize2fs)

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

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

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

Уважаемые авторы предыдущих топиков как-то упускали тот момент (или мне показалось? или это само-собой подразумевается?) что exceptions возникли как инструмент для решения весьма утилитарной задачи —

Гуляя по github'у я много раз видел в разных репозиториях одновременно и теги вида «v2.3.4» и коммиты с сообщениями типа «Bump version» и сменой номеров версии где-нибудь в lib/version.rb. И всегда мне казалось — что-то тут лишнее.

И когда пришло время задуматься и мне над расставлением номеров версий, я сказал: «Нет! Я не буду прописывать эти номера в файлы руками. Пусть это делает за меня моя система контроля версий!»

Признак того, что объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция».

Каждый раз когда из написанного класса вы создаёте всего один экземпляр, используете только раз и тут же выбрасываете, следует думать: «ой, надо бы это отрефакторить! Можно сделать проще, намного проще!»

Перевод доклада Джэка Дидриха, одного из ключевых разработчиков языка Питон. Доклад прозвучал 9 марта 2012 на конференции PyCon US.

Проблемы с русскими символами в git

Когда вы начнете работать с версией git под windows в командной строке, вы столкнётесь со следующей проблемой — все сообщения git, в которых фигурируют русские символы будут нечитаемы. Имена файлов, на русском языке, будут выглядеть так — "\362\345\361\362", а тексты коммитов примерно так — <C8><ED><E8><F6><E8><E0><EB><E8><E7><E0><F6><E8><FF> <EF><F0><EE><E5><EA><F2><E0>. Т.е. исходная строка преобразуется в utf8 в соответствии с кодировкой latin1.

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

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



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

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

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

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

1 Вступление

В топике освещаются не столько подробности работы с git, сколько его отличия от схемы разработки других систем контроля версий, и общий подход (выработанный по большей части личным опытом и Git Community Book) к работе.

1 Введение

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

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

Однажды Альберт Эйнштейн сказал: «Я не знаю, чем будут воевать в третьей мировой войне, но в четвертой мировой люди будут воевать дубинками».
Хочется по этой же схеме перефразировать ученого: «Я не знаю, как будет выглядеть “Web 3.0”, но считаю, что “Web 4.0” будет характеризоваться максимальной закрытостью социальных связей и персональных данных».

Когда появился Интернет, он, прежде всего, стал средством соединения людей между собой. Его удобство для коммуникации людей было однозначно неоспоримым (прочие дифирамбы опустим).
Люди оказались соединены между собой, но примерно так, как люди держатся за руки в темной комнате: «я знаю, чья ладонь у меня в левой руке, чья – в правой, но не знаю, с кем соединены эти люди свободными руками». Можно много спорить об условности терминов, но как бы то ни было, примем эту систему за «Web 1.0».

Время шло своим чередом, Интернет также развивался. Желание людей соединяться, находить людей с общими интересами и общими знакомыми было подмечено тонко чувствующими структуру момента людьми. Появились социальные сети, наглядно демонстрирующие связи людей. В темной комнате включили свет – и много удивительно интересного оказалось видно не привыкшим к яркому свету глазам: «какой знакомый с кем соединен, какими руками, а кто и не только руками; а вот там, в уголке, и совсем даже не руками». Так появилось то, что сейчас называют «Web 2.0». <p text-align: justify>Наверное, сложно быть футурологом. Обычно это достаточно неблагодарное занятие – предсказывать то, что пока ещё не всем очевидно. Поэтому попробую, скажем так, пофантазировать…