Никогда не приходил в голову вопрос: "а как сохранить/передать в другой поток ссылку на поле?"? Логичным предположением будет «передам ref в метод и сохраню. Стоп, oh shi~». Да, ref не сохраняются (а ещё, нельзя использовать на них замыкания, так что создать функцию внутри такого метода и создать из её поток тоже не получится). Но зато можно превратить ref в TypedReference с помощью недокументированного ключевого слова __makeref. Увы, TypedReference нельзя напрямую сохранить в поле и не наследует от System.Object, так что каст привычными методами тоже невозможен (да и вообще на их использование наложена целая куча ограничений). Казалось бы, тупик. Но это ещё не всё — есть ещё RuntimeArgumentHandle, который обладает свойствами TypedReference, за одним исключением — после хитрого каста в System.Object его ещё можно использовать до тех пор, пока жив кадр стека, в котором он был создан. Об этом этот пост.

Вчера я первый раз написал статью на хабр, не зная местных тонкостей.

Исправляюсь! Теперь понятным языком и с юмором!

Чёрная пятница оказалась воистину чёрной для aмериканского интернет-универмага Kohl's. Все сервера накрылись медным тазом именно в день рождественских распродаж. Привычные 20% годового дохода, добываемые в этот день, обернулись смешным пустяком, а все потому что Боливар не вынес такой нагрузки.

Традиционная архитектура Tomcat + WebLogic + БД облажалась по полной программе! Напрасно бегали по этажам сисадмины, суетились в панике ведущие программисты, а архитекторы выдирали остатки волос… Горлышко бутылки оказалось слишком узким для того, чтобы в него могли протиснуться все потенциальные клиенты и недостаточно эластичным, чтобы за короткое время его можно было успеть расширить. Бутылку разорвало нахрен. И долго еще кровоточили раны, нанесённые ее осколками…

Не так давно для создания сервиса (да и «в загашник» положить модуль) потребовалось придумать способ как быстро из sql базы делать выборки точек расположенных на карте.
Кода будет мало, что бы не отвлекать от понимания системы в целом.

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

Работая в очередной раз с модулем cluster, я столкнулся с необходимостью обмена сообщениями между рабочими процессами. К сожалению стандартный функционал модуля позволяет отправлять сообщения только с master процесса на worker, и в обратном направлении. При этом нет возможности получить какой-то ответ на сообщение, а очень хотелось бы. Поэтому я написал модуль cluster-hub. Возможно кому-нибудь он пригодится.

Модуль позволяет

• Отправлять сообщения master->worker, worker->master, master->master
• Отправлять запросы и получать ответы (через callback)
• Использовать эксклюзивные блокировки по ключу (критические секции)

Кому интересно — прошу под кат.

Обрабатываете много данных в браузере?
Хотите отправлять их обратно на сервер?
Да так, чтобы отправлялось побыстрее и помещалось в один http запрос?

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

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

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

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

После недавней статьи все наверное стали (чаще) использовать теги для «пущей убедительности». ну например
<font color="#FF0000">НЕ забудь деньги!</font>
ну или более убедительный
<font size="42">НЕ забудь деньги!</font>
ну и вот, во что это вылилось:

ещё не догадались в чём дело?

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

Если вы сами проводили конкурсы и всё было ок — не читайте топик. Если где-то ждал облом — добро пожаловать под кат.

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

   <div id="block_outer">
      <div id="block_inner"></div>
   </div>

А теперь представьте, что к блоку #block_outer привязано событие onClickOuter, а к блоку #block_inner, соответственно, событие onClickInner. И ответьте на вопрос, как сделать так, чтобы при клике на блок #block_inner, событие onClickOuter не вызывалось? И будет ли оно вообще вызвано? И если будет, то в каком порядке события будут вызываться? И знаете ли вы, как работает метод jQuery.live или подобные в других библиотеках (events delegation в ExtJS, например)?

Привет Хабр,
Меня вводит в ступор С++. Вот просто, зависаю над монитором, смотрю в окно, попиваю чай… И начинаю жалеть за бесценно проведенные годы за изучением стандарта С++, попытками написать свой фронт-энд компилер. Эти мудреные книжки С++ In Depth. Как же я негодовал, когда не понимал кода из книги Александреску. Как записывал все постулаты Страуструпа и иже с ними. Зачем? Вот спрашиваю себя, зачем я теперь все это знаю. Более, я хочу сказать, что этот язык нещаден для гуру, не с медицинской, не с экономической точки зрения! Он не оправдывает усилий, вложенных в его изучение — раз. На практике, он экономически не выгоден — два. И нервные клетки подтвердят, что сопровождать чужой плюснутый код — бывает опасно для здоровья -три. Пусть тут будут рандомно разбросаны метафоры, пишу как есть, из опыта.

Обычно концепции или парадигмы программирования объясняют либо описательно — «разжёвывая» новые идеи простыми словами, либо метафорически — уподобляя их хорошо знакомым аудитории предметам и понятиям. Но ни первый, ни второй способ не дает такого точного и полного представления о предмете, как взгляд с точки зрения низкоуровневой реализации.

Когда в изучении языка доходишь до нетривиальных вещей, бывает полезно сместить уровень абстракции, чтобы понять, как на самом деле всё устроено. Ведь, по большому счету, любые конструкции языков сколь угодно высокого уровня сводятся к старому доброму машинному коду. Писать в объектно-ориентированном или функциональном стиле можно и на чистом C, и даже на ассемблере. Грубо говоря, любой высокоуровневый язык — это зафиксированный на уровне компилятора или интерпретатора набор синтаксических карамелек и шоколадок. Повышение уровня абстракции позволяет писать более сложные программы с меньшими усилиями, но вот понять в начале пути, что конкретно имеется в виду под наследованием или замыканием, как это всё работает и почему, гораздо легче, разобравшись, каким образом всё это реализовано.

JavaScript, как никакой другой язык, нуждается в именно таком объяснении. Функциональная природа, скрытая за Си-подобным синтаксисом, и непривычная прототипная модель наследования поначалу сильно сбивают с толку. Давайте мысленно понизим уровень JavaScript до простого процедурного, наподобие Си. Отталкиваясь от этого «недоязыка», переизобретем функциональное и объектно-ориентированное программирование.