Вирус, атаковавший ядерные объекты Ирана, ознаменовал начало эпохи кибернетических войн.
Мир — на грани военной IT-революции? Факты. Комментарии. Аналитика.

«Не знаю, каким оружием будут сражаться в третьей мировой войне, но в четвертой в ход пойдут камни и дубинки»
Альберт Эйнштейн

В конце сентября стало известно, что вирус Stuxnet нанес серьезный урон иранской ядерной программе. Используя уязвимости операционной системы и пресловутый «человеческий фактор», Stuxnet успешно поразил 1368 из 5000 центрифуг на заводе по обогащению урана в Натанзе, а также сорвал сроки запуска ядерной АЭС в Бушере. Заказчик – неизвестен. Исполнитель – нерадивый сотрудник Siemens, вставивший инфицированный флэш-накопитель в рабочую станцию. Ущерб, нанесенный ядерным объектам Ирана, сопоставим с ущербом от атаки израильских ВВС.
Мир заговорил о войнах нового поколения. Кибернетические атаки могут стать идеальными инструментами следующих войн – они стремительны, эффективны в своей разрушительности и, как правило, анонимны. Сегодня государства в спешном порядке договариваются о совместной стратегии противостояния кибернетическим угрозам. Что будет завтра? К сожалению, наиболее реалистичным ответом на этот вопрос до сих пор остается невеселый афоризм Эйнштейна.

Статья может помочь вашему живому проекту не тормозить(или тормозить меньше), либо стать отправной точкой для исследования стороннего продукта.
Например, у вас стоит задача понять что же происходит внутри «Самописная система 3.14» и, опять же, помочь ей не есть по 100 мегабайт RAM на одного клиента.

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

В этом топике мы в общих чертах рассмотрим процесс реализации непрерывной интеграции на примере TeamCity Enterprise 6.0 EAP (build 15400) и обратим внимание на применении инструментов рассмотренных в прошлой теме: Обеспечение качества программного продукта.

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

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

Примеры будут извлечены из нашей любимой зверюшки — бота-руткита TDSS, о котором в последнее время много говорят. Что и не удивительно: это один из наиболее распространенных, технически продвинутых и активно развивающихся ботов.

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

от переводчика: Перевод немного вольный, не обессудьте — оригинал очень большой. Но смысл постарался передать. Осторожно, много букв!

Многие люди не очень хорошо понимают, чем занимается Y Combinator (YC). Цель этой статьи подробно описать процесс работы, пожалуй, самого успешного инкубатора стартапов в мире.

YС проводит два трехмесячных цикла финансирования в году: с января по март и с июня по август. Они просят основателей каждого стратапа, который финансируют, приехать в Bay Area на весь цикл финансирования, в ходе которого YC интенсивно работает с ними, чтобы получить компанию в наилучшей форме. Каждый цикл завершается мероприятием под названием «День Демо», в который стартап представляют аудитории, которая в настоящее время включает в себя большинство из крупнейших в мире инвесторов стартапов.

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

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

Samy Mamkar разработал систему, которая позволяет хранить куки в 8 местах, автоматически восстанавливая друг друга, и даже добиться того, чтобы куки, поставленное в одном браузере, действовало и в другом.

Удалить это куки практически невозможно! (Все возможно, конечно, но слишком много мороки)

Куки хранятся в:

• HTTP Cookies;
• Local Shared Objects (Flash);
• Сохранение куки в значениях RGB автосгенерированных и форсированно кэшированных PNG с использованием HTML5 canvas;
• Сохранение куки в Web History;
• HTML5 Session Storage;
• HTML5 Local Storage;
• HTML5 Global Storage;
• HTML5 Database Storage через SQLite.

При удалении из одного из этих мест кука автоматически восстанавливается из оставшихся. Работает даже если пользователь сменит браузер (через Local Shared Objects из Flash).

Описание (на английском) и демо: http://samy.pl/evercookie/.
Попробуйте удалить куки, почистить систему и зайти назад.



Как пользоваться?

Я встретился с новым типом ботнета. Если старый долбил только в главную, то новый действует иначе. Он посылает множество запросов вида
GET someurl/?t1555ss5326=5326, где someurl — найденный ботом php скрипт.
Но если атакуемый сайт поддерживает ЧПУ, то такие запросы к нему должны отсутствовать в принципе. ЧПУ сейчас является стандартом де-факто, по этому можно смело отрезать такие запросы, логируя IP ботов.
Для этого очень удобен nginx, и его переменная is_args, которая имеет значение "?", если в URI идут аргументы. Базовая конструкция выглядит так:

if ($is_args = "?") {
return 403 444;
}

Очень просто и красиво, правда?
Вот как выглядит LA после включения этой защиты:
load average: 1.50, 3.09, 6.96
Текущий ботнет из ~20000 зомби, делают 5-8k одновременных запросов.

Прочитав статью об основателе ooShirts.com Ричарде Лэе и его бизнесе, опубликованную на Хабре 9 сентября, я очень обрадовался: наконец-то об ультралегких стартапах, которые прекрасно себя чувствуют в “западных интернетах”, заговорили по-русски.

Однако комментарии к посту оптимизма поубавили, и в то же время заставили задуматься: почему отечественный “интернет-деятель” ищет десятки причин, вроде бы объясняющих нереальность повторения успеха Лэя в Рунете (под повторением имею в виду не копирование идеи, а воспроизведение модели ультралегкого стартапа, а уж продукт или услуга могут быть какими угодно), вместо того, чтобы использовать возможности, которые уже есть… или создать новую бизнес-модель, но на базе существующих сервисов?

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

А уж как именно почковаться — зависит от специфики бизнеса. Компания Лэя доверяет печать и отправку заказов стороннему производителю; разработчики приложений в социальных сетях адресуют их многомиллионной аудитории ВКонтакте или Фейсбука; сервисы коротких ссылок обрели популярность благодаря Твиттеру и прочим микроблогам и т.д.

Но если всё так просто — что делает отдельные министартапы звёздами, о которых пишут газеты и блоги? Почему на фотографии именно Ричард Лэй, а те, кто громко кричит о том, что “у нас такое невозможно” — лишь в комментариях? Попробую, не претендуя на истину в последней инстанции, изложить свою версию ответа на этот вопрос, тем более, что получил я его благодаря другой публикации на Хабре… впрочем, обо всем по порядку.

На написание данной заметки натолкнула одна интересная статья “Anchoring effect”. Однако это совсем не перевод, так как в тексте встречается много лишней информации и исследований в духе «Британские ученые доказали…» Это скорее творческая интерпретация.

В статье описывается один очень важный психологический эффект – эффект якоря или эффект привязки.

В чём секрет?

Когда вам говорят «Только не думай о розовой обезьяне» — вы начинаете о ней думать. Но это пустяки, по сравнению с подсознательным смещением в восприятии числовых показателей.

Чтобы что-то оценить, нам необходима отправная точка, некий якорь – что-то вроде «розовой обезьяны».

Например, если спросить – сколько человек составляет население Венесуэлы, что вы скажете? Растеряетесь и задумаетесь. А если задать вопрос: «Население Венесуэлы больше или меньше 65 млн?». Вопрос приобретает иной окрас, и ваш мозг подсознательно начинает опираться на упомянутую цифру, даже если она взята «с потолка». Какой ответ вы дали в первом и втором случае? Во втором случае названное число будет намного больше, чем в ответ на первый вариант вопроса.
А между тем – в Венесуэле живет всего 28 млн человек.

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

Вступление

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

Навеяно вот этим.

Я решил вспомнить некоторые особенности PHP, связанные с производительностью.

Отмечу, что включил в свой небольшой список лишь то, что обычно вызывает удивление у junior developers, с которыми мне приходилось работать.
О банальных вещах, вроде «одинарные кавычки вместо двойных», думаю, знают все, поэтому постараюсь кого-нибудь удивить.

Результаты и выводы, сделаны на основании нескольких версий PHP, который крутятся на знакомых мне серверах, а именно 5.2.6 из Debian Lenny, 5.3.2 из Ubuntu, и 5.2.14 из dotdeb. Возможно, на других платформах, есть отличия.

Три года назад у меня была интересная задача. Необходимо было собрать платформу, объединявшую несколько стоек с серверами в единое целое, для динамического распределения ресурсов между сайтами написанным для LAMP платформы. Причем так, чтоб вмешательство в код сайтов было минимальным, а еще лучше — вообще отсутствовало.
При этом никаких дорогих решений вроде Cisco Content Switch или дисковой полки с оптоволокном использовать нельзя — не хватало бюджета.
А кроме того, разумеется, в случае выхода одного из серверов из строя — это не должно было влиять на работу платформы.

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

Несколько лет назад ко мне пришел мой босс и сказал: «У нас есть новый проект для тебя. Это перенос сайта, который уже имеет 1 миллион посетителей в месяц. Тебенеобходимо его перенести и убедиться, что посещаемость может вырасти в будущем без всяких проблем.» Я уже был опытным программистом, но не имел никакого опыта в области масштабируемости. И мне пришлось познавать масштабируемость трудным путем.

Команда Jupiter IT выпустила Syn, библиотеку, которая позволяет вам создавать синтетические события для использования при тестировании. Эта отдельная библиотека предназначена для оказания помощи в тестировании сложного поведения пользовательского интерфейса, имитируя действия пользователя, такие как печать с помощью клавиатуры, нажатие кнопок мыши и перетаскивание с её помощью.

Юридическая компания MLG Consulting совместно с адвокатом Мариной Деревянко (Адвокатская Палата Санкт-Петербурга (СПбГКА) объявляет о создании правового FAQ для стартаперов.

Вопросы можно оставлять в комментариях, отправлять по электронной почте info@mlgconsult.ru или задавать через твиттер @mlgconsulting до 10 июля 2010 г. Вы можете задать любой вопрос о создании ИТ-бизнеса, авторских правах, привлечении инвестиций и любой другой вопрос из области ИТ-предпринимательства.

Ответы выйдут в качестве бесплатной брошюры и будут размещены на сайте юридической компании MLG Consulting и ресурсах Марины Деревянко. Помимо этого, будут даны комментарии к заданным в данном посте вопросам.

Всем привет,

Собираюсь поделиться с вами технической стороной того, как я за 16 недель сделал новый вебовый rss ридер, и чуть не сошел с ума.
Отходя от долгой предыстории, будем считать, что все началось в феврале этого года, когда мы с Дэвидом (dmiloshev, UI-дизайнер) решили сделать прототип нашего детища вдвоем.
«В одиночестве» — потому, что не было никаких скрамов, совещаний, «коллективного разума», а всю техническую часть, довелось делать самому.

Если бы меня попросили описать всю статью в одном предложении, то получилось бы:
No-SQL, mongodb, node.js, фак мой мозг, Evented I/O, очереди, выводы, git, nginx, memcached, Google Reader, Atom, TTL, PHP, ZF, jQuery, выводы.

Некоторым везет. Вы точно знаете такого. У него на столе широкоформатный монитор, которым можно заменить экран в кинотеатре. Компьютер, приютившийся под дорогим дубовым столом, мощнее WOPR из старого фильма «Военные игры». И, конечно же, не забываем, что всё это в отдельном кабинете, в котором даже можно закрыть дверь на ключ (само собой, по исключительно важным поводам). И если вам людишкам из-за офисных перегородок этого мало, то вспомните, что этот чувак отвечает за самые крутые проекты и использует самые сексуальные и новейшие технологий. Он из тех, кем все прочие смертные тоскливыми ночами мечтают быть, вместо того чтобы спать. Но какого же ему так везет?

Я уже несколько лет занимаюсь внедрением систем электронного документооборота (СЭД). Начинал свой профессиональный путь в небольшой IT-компании, в которой работало около 10 человек. Компания внедряла коробочные решения СЭД в различных органах государственной власти. После этого я работал еще в нескольких компаниях, какие-то из них были очень даже серьезными, с серьезным подходом к проектам и серьезными бюджетами. Но независимо от масштабов компании и «раскрученности» внедряемой платформы, большинство моих проектов были нецелесообразными.
Это не значит, что все проекты были убыточны. Какие-то из них имели технико-экономическое обоснование, а какие-то даже ему соответствовали, и были действительно экономически выгодными. Но экономическая эффективность это не единственная величина определяющая целесообразность проекта.