Планирование, постановка задачи, контроль — вот одни из важных принципов на которых строится управление проектами и web проектами в частности. А в процессе руководства удаленными командами и организации взаимодействия между ними, без использования систем постановки и контроля задач не обойтись.
В данном посте я хочу рассказать о самой популярной системе багтрекинга BugZilla и успешном ее внедрении и эксплуатации в веб-студии «Твинс». Почему-то на хабре БагЗиллу всегда упоминают вскольз. Но никто и никогда подробно не ней не останавливался. А зря…

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

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

========== Build: 258 succeeded, 1 failed, 40 up-to-date, 1 skipped ==========

А помимо недоумения закономерный вопрос: а что, собственно, сломалось? Есть, конечно, вкладка «Error list», но она к сожалению не показывает названий проектов — только файлы, а при таком объеме исходного кода, да с учетом того факта, что над этим solution'ом работает большая команда, довольно проблематично определять на память принадлежность того или иного файла к определенному проекту (читай определять виновных в сломанной сборке). Пролистывать же отчет в поисках имени проекта, содержащего ошибки, на мой взгляд, не совсем целесообразно.

Принимая во внимание всё вышесказанное, я решил совместить приятное с полезным, получив небольшое представление о том, что же такое VS Exstensibility, снабдив при этом студию маленьким «удобством». «Удобство» должно позволять одним кликом мыши отсеять все ненужное из отчета о сборке, оставив только сообщения об ошибках и имена проектов, их содержащие.

На написание этого опуса меня сподвиг данный пост, так как в нем некоторые моменты освещены недостаточно подробно. Ниже я опишу на собственном примере реализацию автоматической качалки торрентов с Lostfilm-а пр помощи FlexGet и Deluge. Все будет проиходить под Ubuntu 9.10

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

Способы я перечисляю в порядке убывания точности и, к сожалению, в порядке возрастания вероятности срабатывания.

1. NS-сервера

Даже странно, что забыл упомянуть с самого начала. Спасибо variable За напоминание. Очень часто люди пользуются NS-серверами хостера и при помощи whois'a мы моментально узнаем хостера.

Плюсы

• Очень часто срабатывает на шаред-хостингах

Минусы

• Зачастую пользователи VPS и дедиков, а так же продвинутые пользватели на шаред-хостингах пользуются своими DNS-серверами, либо используют свои поддомены.

2. Ошибка 403/404

Не могу сказать, что большинство, но немало серьезных хостеров страницы ошибок веб-сервера по умолчанию делают с информацией о себе, а многие их клиенты забывают/ленятся их переопределить. Поэтому в первую очередь стоит попытаться вызвать такую ошибку и посмотреть, что получится. Бывает так, что CMS на сайте при помощи mod_rewrite перехватывает запросы к несуществующим файлам и отдает в ответ свою 404-ю ошибку. Это можно попробовать обойти, вызвав ошибку 403 путем обращения к какталогу без индексного файла. Им может быть папка с картинками/шаблонами, папка для загруженных файлов, кэша движка, системная папка типа includes и т. п. Небольшой хинт — иногда на странице ошибки есть email вебмастера и часто из него можно узнать домен сайта хостера.

Ниже по тексту термином «платформа» будем называть любой заданный набор из процессора, компилятора и операционной системы, под которой скомпилированный код будет запускаться.

Исторически язык C создавался таким, что среди главных целей, положенных в его основу есть такие:

• быть максимально независимым от какой-то конкретной платформы,
• быть максимально эффективным на всех платформах. В идеале — на всех.

Немножко о разнообразии платформ. Их (платформ) существует огромное количество — среди процессоров есть и 16-битные, и 32-битные, и 64-битные. Есть такие, которые умеют выполнять операции с плавающей точкой на аппаратном уровне, какие-то поддерживают операции с двойной точностью, а в каких-то процессорах FPU отсутствует полностью. Процессоры отличаются также внутренним порядком следования байт в слове (big/little endian), как именно процессор работает с внешней памятью, и т.д. и т.п.

И на весь этот зоопарк существует один-единственный Стандарт языка C. Как же это удалось? Вот тут и начинается самое интересное.

В мире ПО существует огромное количество программ, забытых своими разработчиками. Хорошо, когда уже есть хорошая альтернатива. А если ее нет? В программе может катастрофически не хватать каких-то мелочей, некоторые досадные ошибки могут годами доставлять массу неудобств пользователям, а на новых версиях ОС программа и вовсе может отказаться работать. Далеко не всегда имеются исходные коды, чтобы привести программу в порядок. Если программа простая — не составит труда за короткий срок создать альтернативу. Но если программа большая и сложная, что же делать в таком случае? Не всегда рационально тратить время и деньги на разработку полного аналога, ведь расширить в разумных рамках функциональность и исправить большинство ошибок можно уже в готовом исполняемом файле.
В этой статье будут продемонстрированы методики модификации исполняемых файлов на примере расширения функциональности легендарной игры Age of Empires II (стратегия реального времени).

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

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

Всем привет. А особенно тем, кто пишет на плюсах и интересуется грядущими изменениями языка.
Для исследования фич нового стандарта С++ я сделал забавную штуку — функцию для превращения простого функтора в ленивый. Т.е. вычисляемый не более одного раза, и только при первом обращении.
Для использования вам понадобится простой функтор, без аргументов, возвращающий значение.
Применяете к нему calc_once(some_func) — и он становится ленивым.

auto my_func = calc_once([]{ return SomeHugeCalculation(); });
if ((my_func() && some_case) || (!my_func() && some_other_case))
{
}

* This source code was highlighted with Source Code Highlighter.

Под хабракатом код, там и auto, и decltype, и лямбды.

UPD. Спасибо за карму. Перенес в блог С++.

Приветствую вас, хаброчеловеки!

Сегодня хочу похвастаться моддингом своей флешки =)
А было все так… Выдался свободный вечерок, хотелось поесть чего-нибудь вкусненького, — а под рукой была только полимерная глина…

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

Итак, в новостях снова пишут, что кто-то еще умер из-за игромании. Да, опять Корея.

Какого ...? послушайте, я не пытаюсь доказать что видео игры — это героин. Я полностью понимаю, что в данном случае у жертвы было много проблем в жизни. Но, половина из вас знает что World of Warcraft затягивает и что доктора считают игровую зависимость серьёзной проблемой. А вопрос вот в чем: может быть какие-то игры намеренно разрабатывались, чтобы заставлять вас играть в них, даже если вы не получаете от этого удовольствия?

Жаль не умею рисовать, но это очень круто.

UPD: обратите внимание, статья описывает устаревший успешный опыт переноса доменов.

Здравствуй, Хабрасообщество и его уважаемые читатели!

Однажды я узнал что умные люди давно регистрируют/продлевают домены в зоне ru по 99 руб у партнера регистратора «REG.RU» — 2domains.ru. Подумал «надувательство какое-то». Но, наступил день когда мне понадобилось зарегистрировать домен, подешевле и побыстрее. «Чем черт не шутит» подумал я и зарегистрировался на 2domains.ru. Перечислил с Webmoney 99 рублей, затем заполнил нехитрую анкету (персона на которую регистрируется домен,- эта же информация отображается и в whois). Указал имя домена и нажал заветную кнопку «зарегистрировать домен»!

Наверное, все, работающие с Java, знают об управлении памяти на уровне, что для ее распределения используется сборщик мусора. Не все, к сожалению, знают, как именно этот сборщик (-и) работает, и как именно организована память внутри процесса Java.

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

При разрабокте приложения мы будем использовать утилиту Ant для автоматизации действий и изучим, как писать простой тест с помощью библиотеки JUnit. Весь код будем писать в Eclipse IDE.

Статья написана на основе первой части руководства «Introduction to Spring MVC». Вам достаточно иметь лишь общее представление о Spring, чтобы прочитать статью с пользой.

Так что милости просим :)

Вступление

Недавно мне потребовалось перенести несколько сайтов различных клиентов на нормальный выделенный сервер (не виртуальный). Я давно выбирал, где лучше арендовать сервер и выбором стала немецкая компания Hetzner Online и ее тарифный план DS 3000 (AMD Athlon 64 X2 4200+/2Gb DDR/2x160Gb HDD — как выяснилось потом — на сервере оказалось два винчестера по 320Гб).

Но мне не хотелось всех размещать на одном сервере. Поэтому было решено сделать виртуальные машины на базе технологии XEN (к тому же в придачу к серверу на ТП DS 3000 Hetzner Online бесплатно выдает 6 IP-адресов, которые очень удобно будут смотреться для отдельных проектов). В Сети можно найти много информации по теме настройки и самого XEN'а на Debian'e и настройки роутинга на нем, поднятии виртуалок на LVM (lvm дает большее быстродействие, чем виртуалки на базе image-файлов), даже в вики самой фирмы была информация об этом (но на немецком — Google Translate нам в помощь). Но. Было одно «Но». Она вся была разрозненная и кусками. Я нигде не смог найти толкового пошагового руководства для настройки «от» и «до».

Поэтому, всем кому интересна эта тема,

   На Хабре уже было пару статей, о весьма неплохом роутере WL 500G Premium от ASUS.
   В устройстве заложен неплохой потенциал – довольно шустрый процессор BCM4704 фирмы Broadcom, 32 Мб оперативной памяти, наличие двух портов USB (хоть и с не высокой пропускной способностью). Подкачал Wi-Fi модуль, предел которого составляет 54Mbps при использовании 802.11g. Но для ноутбука, нетбука, коммуникатора и других мобильных устройств вполне достаточно.



   Данная начинка просто требовала более правильного использования, чем этого хотели программисты ASUS. Посему были созданы как модификации родной прошивки (прошивка от Oleg`a oleg.wl500g.info), так и полностью новые проекты (DD-WRT www.dd-wrt.com).
   Весьма востребованной оказалась возможность подключения внешнего жесткого диска по USB интерфейсу и установка торрент-клиента (Transmission, rtorrent), что бы разгрузить большого брата и спать ночью в полной тишине.
   Все эти операции были проделаны (об этом можно будет написать еще одну статью) и был получен своеобразный сидбокс, который весьма хорошо справлялся со своими обязанностями.

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

Мы решили объединить все наши знания в единый труд, в котором будут рассмотрены сразу все вопросы, касающиеся 64-битного программирования. Для оформления в виде статьи материала оказалась слишком много и мы решили представить его в виде курса уроков.

Кратко опишу курс "Уроки разработки 64-битных приложений на языке Си/Си++" и приведу его содержание.

Возможно в Вашем проекте и не пишут try { /* code */ } catch(...) { } для того чтобы избежать исключений при работе с памятью, умеют закрывать хендлы и знают о виртуализации Windows Vista, а программы никогда не падают по непонятным и редко повторяемым причинам.

Тогда Вам повезло, можете переходить к следующему топику.

Привет всем. Основываясь на предыдущем опыте, считаю нужным сразу расставить все точи над ё. Описанная ниже методика — не мое изобретение. Однако из собственного опыта могу уверить вас, что она работает. Ровно так, как обещано.
Идея, описанная в посте, появилась давно (под катом есть история), в том виде, в каком расскажу ее я, по большей части она представлена в чудесных книгах Тони Бузана Use You Head и The Speed Reading Book (в последней много воды).

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

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

Прежде чем приступить к самому главному, прошу вас пройти тест из шести вопросов на Да/Нет.

1. Чтение со скоростью свыше 1000 слов в минуту невозможно?
2. Медленная скорость чтения способствует лучшему пониманию текста?
3. Пропускать слова во время чтения — плохая привычка, ухудшающая понимание текста?
4. По умолчанию мы все читаем с «естественной» для нас скоростью, а следовательно, наилучшей?
5. Если вы не поняли слово или предложение, лучше перечитать его и понять?
6. Ваши глаза находятся в непрерывном движении во время чтения?
За результатами и, наконец-то, интересными штуками добро пожаловать под кат.