Задача, подобная этой на использование совместных ресурсов:
1-го сентября 100 бессмертных эльфийских воркутинских зэков постоили на торжественную линейку и предложили им ускорить процесс своего освобождения. Итак, в тюрьме есть камера с висящей лампочкой. Лампочку можно включить или выключить. Каждый день, начиная с 1-го сентября тюремщик будет запускать одного заключённого в эту камеру. В этот момент зэк сможет увидеть, горит ли лампочка.
У каждого заключенного тюремщик будет спрашивать: «А все ли твои товарищи тут были хотя бы раз?» Если зэк отвечает «нет», игра продолжается.
Если зэк отвечает «да» и это правда — всех выпускают на волю в тундру. Если же это неправда — высшая мера наказания для всех.
Тюремщики могут выбирать заключенных вразброс и с повторениями. Заключенные сидят в одиночных камерах и могут договориться только один раз — 1-го сентября на обеде после торжественной линейки. После этого они сидят в «одиночках» без окон, совсем не видят друг друга и лампочки.
Найти оптимальную стратегию поведения каждого заключенного с тем, чтобы их выпустили пораньше.

Простой способ защиты от HTTP DDoS — включить syn-cookies и заблокировать подонков. Но что делать если атакует 5к-10к хостов да еще и с динамическими IP? Тут нам на помощь придет frontend-backend архитектура c промежуточным кэшированием! Почему с промежуточным кэшированием? А потому что в моем случае от шквала запросов от frontend'а backend умирал унося за собой систему.

Добрый день!

Публикация нескольких статей о Data Mining показала высокий интерес сообщества к данной теме. Много вопросов было задано по типу «где почитать» и «с чего начать». Предлагаю вашему вниманию подборку литературы, ресурсов для уверенного старта в данной области.

Хочу представить свой перевод статьи «Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews».

Я ненавижу тебя: твой код – хлам!
Взаимоотношения участников ревизий кода

Джонатан Лэндж (Jonathan Lange), 15.09.2008

Обзор

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

Мы кратко рассмотрим, почему следует проводить ревизии кода, и сделаем упор на вопросе, как складываются при этом взаимоотношения участников процесса, в особенности в проектах с открытым исходным кодом. Действительно, отчасти open source привлекает (а порой наоборот отпугивает!) людей именно потому, что ваш код будут просматривать эксперты со всего земного шара. Мы также рассмотрим влияние, оказываемое некоторыми существующими технологиями на культуру ревизий кода, рассмотрим, чего можно достичь с их помощью, и как проводятся ревизии в других сферах деятельности. Мы также обозначим некоторые «подводные камни» ревизий, которые легко не заметить.

Как бы вы не относились к iPhone, вы не можете отрицать, что этот телефон захватил хороший кусок рынка мобильных устройств. И, по моему мнению, именно он дал возможность нормально пользоваться интернетом с телефона. Но хотя встроенный safari полноценен (спасибо, Webkit), многим хочется сделать специальную версию сайта для iPhone, выглядящую как настоящее айфоновское приложение (например, iweather.yandex.ru).
  
Одной из наиболее популярных библиотек для создания адаптированной версии сайта является iUI.

InfoVis Toolkit — предоставляет инструменты для создания интерактивных представлений данных в Веб с помощью JavaScript. Распространяется с открытым исходным кодом под лицензией BSD. Поддерживаются основные браузеры: IE6+, Firefox2+, Safari3+, Opera9.5+

Еще одна капля в наш стакан Руби (1, 2, 3, 4, 5, 6, 7, 8, 9, 10). Поговорим о self, работе с CSV и обработке исключений.

Описывая и обсуждая компьютерные программы, мы часто используем образные и человеческие метафоры. Например, мы говорим, что находимся в классе или возвращаемся из вызова метода. Иногда имеет смысл говорить во втором лице, например, object.respond_to?("x"): “Эй, объект, ты ответишь на х? И пока программа интепретируется контекст меняется снова и снова.

Некоторые объекты везде означают одно и тоже, например, числа и ключевые слова вроде def и class. Однако значение большинства элементов зависит от контекста.

Для своего нового проекта я как раз сейчас устанавливаю рабочее окружение, и ключевое место в нем занимает баг/таймтрекер+wiki. Платные реализации извесны (тот же Basecamp, Fogbugs, updatelog.com), но хотелось найти что-то что хостится на моём сервере. Из извесного и хорошо работающего — это Bugzilla (с очень скромным функционалом), Trac(есть все, но только 1 проект), и вот только что наткнулся на «новый» проект (около 3-х лет ему) — Redmine. Практически аналог вышеупомянутых платных сервисов, но бесплатный. Проблема для меня в том, что он написан на Ruby On Rails, и как оказалось деплоймент ROR приложений может быть не слишком простым (по крайней мере для таких новичков в этом деле как я). Так как хостинг не специализируется на Ruby, Passenger-а нету. В конечном итоге оказалось что это все не так уж и сложно :-)

В этой статье я хочу по возможности полно и последовательно рассказать о том, что такое объект в JavaScript, каковы его возможности, какие взаимоотношения могут строиться между объектами и какие способы «родного» наследования из этого вытекают, как это все влияет на производительность и что вообще со всем этим делать :)

В статье НЕ будет ни слова про: эмуляцию традиционной класс-объектной парадигмы, синтаксический сахар, обертки и фреймворки.

Сложность материала будет нарастать от начала к концу статьи, так что для профи первые части могут показаться скучными и банальными, но дальше будет намного интереснее :)

Многие пользователи Opera и FireFox знают о существовании так называемых Mouse Gestures (для FF существует одноименный плагин) — жестов мышкой, на которые реагирует браузер выполняя различные действия (такие как открытия нового окна, закладки, назад, вперед и т.д. и т.п.), единственный недостаток данной фичи — нет взаимодеймствия с сайтом, и я решил написать небольшую бибилотечку, которая поможет разработчикам добавить подобный функционал на свой сайт…

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

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

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

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

Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

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

Однако всё это бессмысленно без человека, способного пожинать плоды появляющихся возможностей. Сеть машинно-читаемых данных (семантический веб или сеть данных) далека от вычёркивания человека из процесса. Более того, она открывает огромные перспективы для взаимодействия человека и машины.

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

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

Здравствуй хабрачитатель. Сегодня я решил поделиться с тобой своими мыслями по поводу DDoS- атак. Что это такое я не буду рассказывать – об этом сегодня знает, по-моему, даже школьник. В общем, отражая в очередной раз могучую атаку хулиганов на один из моих ресурсов, я подумал, а не предложить ли мне сообществу образованных людей ряд идей по борьбе с одним из наиболее распространенных методов подобных атак – HTTP – флуд.

Суть данной атаки сводится к следующему – зараженные компьютеры, управляемые головным сервером генерируют огромное количество запросов вида:

"GET / HTTP/1.1" XXX XXXX "

Запросы естественно могут быть на любую как существующую страницу атакуемого ресурса, так и не существующую. Причем в зависимости от «образованности» ботнета и его владельцев, атака может идти сразу на несколько URL и в зависимости от действий администраторов атакуемых ресурсов еще и менять тактику атак.

Что такое веб-сервисы?

Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.

Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

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

Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.

Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.

Недавно озаботился поиском адекватного решения для защиты некоторых подконтрольных ресурсов от DDos атак.
Первое что посоветовали — Cisco Guard. Но так как требовалось что то легкое и не столь дорогое, то решил посмотреть в сторону софтверных продуктов.
После непродолжительного гугления наткнулся на небольшой скриптик (D)DoS-Deflate

На технику Сетки я обратил внимание около года назад. Тогда эта техника после очень поверхностного изучения показалась мне бесполезной и очень экспериментальной, отталкивало то что для реализаций необходимо создавать лишнюю разметку. Но сейчас уже становится трудно не замечать количество веб-сайтов построенных на сетке, а так же количество статей и уроков о ней. Благодаря последним стало гораздо проще изучить и понять принципы и концепцию, сделать более менее реальные выводы. Мой вывод спустя год таков — «Это простое и полезное решение которое когда либо было создано для вёрстки веб-страниц, должен знать каждый уважающий себя веб-дизайнер.»

Изначально искал маленькую ёмкую шпаргалку по FreeBSD, которую в итоге и нашёл, но через пару минут перед моими глазами предстало

НЕЧТО

БОЛЬШЕЕ И

ВСЕОБЪЕМЛЮЩЕЕ

P.S. pdf inside
P.P.S. и не только по FreeBSD…