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

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

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

Думали ли Вы когда-нибудь о том, чтобы Ваш сайт одинаково хорошо работал с включенным JavaScript-ом и без JavaScript-а? Чтобы, если JavaScript включен, блоки сайта перегружались AJAX-сом, а если JavaScript-а нет, то происходил просто переход на новую страницу?

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

Для себя я сформулировал задачу, по следующим критериям:

• Переход по разделам сайта внутри и вне блоков должен осуществляться обычными ссылками, без каких бы то ни было onclick=”…”.
• При включенном JavaScript-е блоки сайта перегружают только свою область страницы (свой div). При выключенном JavaScript-е должен происходить обычный переход по ссылке.
• Должен существовать только один глобальный обработчик нажатия на ссылки $(“a”).click(…), который и делает всю работу по перегрузке нужных элементов страницы. Если же JavаScript отключен, то этот обработчик просто не срабатывает, и сайт продолжает работать в обычном режиме.
• Постинг форм при включенном JavaScript-е также обновляет только ту область, в которой находится эта форма. При отключенном – все работает как обычно.
• Должна быть возможность запретить AJAX-презагрузку некоторым областям страницы, например, поставив им какой-нибудь класс «noajax». Это если после перехода по ссылке меняется слишком много данных на странице, и они все в разных блоках. Тогда разумней перегрузить всю страницу целиком, чем обновлять каждый блочёк по отдельности. Оно и быстрее будет.
• Должна быть возможность указать ссылке блок, который она должна перегрузить. Допустим, если нам нужно перегрузить не только текущий блок, но и блок родитель.
• Если блок был загружен ранее, то он должен браться из кеша, дабы не гонять лишний трафик и не напрягать лишним запросом сервер.
• В случае, если блок загружен из КЭШа, пользователь должен как-то понимать что эта не самая актуальная информация, и иметь возможность обновить блок.
• Никакого JavaScript-a. Это конечно мое личное мнение, но я ненавижу писать на JavaScript-е. Поэтому я добавил еще один пункт. Смысл его в том, чтобы разрабатывая модули к сайту я не писал ни строчки JavaScript-а (ну максимум одну-две на модуль, и то для каких-нибудь чекбосов в форме). Не знаю, как ты, дорогой хаброчтец, но я, твою мать, лучше продам свою душу дьяволу, чем буду дебажить свой JavaScript во всех многообразиях браузеров!
  

Ну, вот собственно и все пожелания. Итак, приступим к реализации…

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

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

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

Современное кино и телепередачи — это сплошные многомиллионные бюджеты, скандалы, знаменитости и сумасшедшие спецэффекты. В PixelBuzz.tv все наоборот. В нашем распоряжении — 8 цветов, 4 кадра и ограниченный набор пикселов. Каждый может стать режиссером и сделать свой пиксельный ролик, отправив его в общий канал. Все ролики перемешиваются и в случайном порядке отдаются зрителям.

Не так давно мне предложили вести курс основ теории алгоритмов в одном московском лицее. Я, конечно, с удовольствием согласился. В понедельник была первая лекция на которой я постарался объяснить ребятам методы оценки сложности алгоритмов. Я думаю, что некоторым читателям Хабра эта информация тоже может оказаться полезной, или по крайней мере интересной.

В этой статье я расскажу, как отлаживать многопоточные приложения в Visual Studio 2010, используя окна Parallel Tasks и Parallel Stacks. Эти окна помогут понять структуру выполнения многопоточных приложений и проверить правильность работы кода, который использует Task Parallel Library.

Мы научимся:

• Как смотреть call stacks выполняемых потоков
• Как посмотреть список заданий созданных в нашем приложении (System.Threading.Tasks.Task)
• Как перемещаться в окнах отладки Parallel Tasks и Parallel Stacks
• Узнаем интересные и полезные мелочи в отладки с vs2010

Осторожно, много картинок

Приветствую, хабралюди.

OnPHP — это фреймворк, как не трудно догадаться, написанный на PHP. Как и любой подобный инструмент он обладает своими преимуществами и недостатками и, как я считаю, первых у него больше.

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

Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:

как называть узлы и интерфейсы узлов в сети?

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

Добро пожаловать во вторую серию нашего повествования про xdebug. Установка xdebug и его базовые возможности были рассмотрены в первой серии. В данной статье мы рассмотрим трассировку программы.
Предыдущая серия цикла Introducing xdebug

Эта статья первая из серии статей, описывающих xdebug, свободной библиотеки для разработчиков PHP. xdebug – это расширение для PHP, написанное Derick Rethans, одним из разработчиков языка PHP. В данной статье описывается как установить xdebug и рассказывается о его базовых возможностях. В последующих частях мы детальнее взглянем на главные возможности xdebug, а именно трассировку, профайлинг, отладку кода.

Привет, Хабр!

Написал класс, использующий Zend_Db_Table_Select и позволяющий использовать Dynamic Finder в моделях в проектах на Zend Framework. Статья о том, что этот класс умеет, а также ссылка на исходный код предлагаются вашему вниманию.

Что это, зачем?

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

Dynamic Finder позволяет избежать написания ряда методов вида getById(…), getByLoginAndPassword(…), getAllByCountry(…) внутри модели в виде построения полноценных SQL-запросов и выборок. Вместо этого, в данной реализации достаточно подключить Dynamic Finder к модели должным образом, и, далее, программист может использовать эти методы модели непосредственно в контроллере или представлении. При этом реально эти методы в модели вообще не существуют.

Таким образом, экономится время работы программиста.

Dynamic Finder уже был реализован в том или ином виде в различных библиотеках и фреймворках, в частности, в Ruby on Rails.

В данной реализации Dynamic Finder является надстройкой, использующей Zend_Db_Select / Zend_Db_Table_Select, и предназначен для выборок из только одной таблицы.

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

Добро пожаловать в третью статью о xdebug. Уже сейчас вы должны были попробовать xdebug, если нет, сделайте это сегодня ;-).
В первой статье рассказывалось о том, как установить и настроить xdebug, описывались некоторые простейшие возможности, такие как улучшение вывода функции var_dump() или вывод трассировки стека вызовов при получении сообщения об ошибке. Во второй части мы рассмотрели такую возможность xdebug как трассировку. Трассировка содержит все вызовы функций и методов в программе, время запуска, опционально размер памяти, передаваемые и возвращаемые параметры. Лог трассировки может помочь вам понять пути выполнения сложной программы. Вместо того чтобы вставлять отладочный код внутрь программы, вы включаете или выключаете трассировку в тем места где нужно, а потом используете утилиты подобные grep или собственно написанные приложения на PHP для анализа лог файла.

Lucas Martell создатель “Pigeon Impossible”:

“Когда проект только начался, основная задача была – изучить 3D-анимацию, но к концу проекта я провел столько времени над переработкой и полировкой истории только для того, чтобы люди посмеялись.”

За 5 лет он сделал 6 минутный потрясающий мультик. По моему, у него все получилось. Вся история создания, материалы и многое другое есть на сайте http://pigeonimpossible.com/.

Представляю вашему вниманию «анимационную работу» — The Zoomquilt II
Штука весьма интересная и выносящая мозг. Нарисовано в стиле и очень даже неплохо, но главное тут — сама идея… )

P.S. Может напутал с блогом, но более подходящего не нашел
_________
UPD Перенес в блог «Странные Идеи», т.к. была найдена схожая статья, созданная там же еще в далеком 2007-ом :)
UPD2 Первая часть. Спасибо Demlock

Управляемая память в .Net поделена на стек и несколько хипов. Самые важные из хипов – это обычная (эфемерная) куча и LOH. Эфемерная куча – это то место, где живут все обычные объекты. LOH – это то место где живут большие (больше 85000 байт) объекты.

LOH обладает некоторыми особенностями:

• Объекты в LOH никогда не перемещаются
• LOH только растет и никогда не уменьшается (т.е. если объект собран сборщиком мусора, размер LOH все равно остается неизменным)
• Хип LOH освобождается только тогда, когда LOH полностью пуст

Из этих двух особенностей LOH происходят два важных следствия, про которые часто забывают:

• Память в LOH может оказаться фрагментированной. Т.е. происходит то, с чем так боролись в unmanaged мире: в какой-то момент у вас может быть 10Mb свободной памяти, но вы не сможете выделить память под объект размером 1Mb
• Если вы однажды выделили память под большой объект, а потом используете только маленькие, то вы фактически лишаете себя большого куска памяти. При чем, если у вас в LOH был список или хэш-таблица размером N, а вы добавили в него один элемент, то список реаллоцируется и растет в два раза, сответственно размер LOH составит как минимум 3*N (N – исходные данные, 2N – копия данных и резерв под новый размер). Следующий рост потребует в LOH непрерывный кусок памяти размером в 4*N, а так как такого куска в LOH у нас нет (есть только N), его придется позаимствовать из адресного пространства процесса. В итоге размер LOH вырастет до 7*N, и так далее.

Если вспомнить, что LOH аллоцируется кусками по 16Mb, то все происходящее покажется еще более разрушительными. С первым следствием можно бороться аккуратно переиспользуя объекты. Со вторым — не используя большие объекты. Получается как-то не очень, особенно если с большими коллекциями работать все-таки хочется. Посмотрим, что как можно решить эту проблему.