Хабрахабр:
Собственно, вот что мне подумалось? Вокруг нас постоянно происходят правонарушения, оказывающиеся безнаказанными. С одной стороны, потому что милиция полиция зачастую не хочет ими заниматься (пока нет ?плана? на фиксацию N-ного кол-ва определенного вида нарушений). С другой стороны, потому что очень и очень редкий свидетель нарушения пойдет в правоохранительные органы писать заявление (если нарушение это не касалось конкретно него). Вот, например? Едете вы на машине. И перед вами, всех подрезая, летит тонированная машина и уносится вдаль, пролетая перекресток на красный свет. И у вас даже и видеорегистратор в машине есть, который все это дело заснял на видео? Но пойдете ли вы ?доносить? в ГИБДД? Вряд ли вы захотите потратить на это пол своего дня. А нарушитель останется безнаказанным и в следующий раз, пролетая на красный ? может стать причиной ДТП. Читать дальше →
Есть такой зарубежный проект, который называется Machinima. Machinima.com (англ. Machinima, от слов machine ? машина и cinema ? кино; другой вариант: от machine ? машина и animation ? анимация) ? студия, которая создаёт фильмы на основе компьютерных игр. Сайт основан в январе 2000 года Хью Хэнкоком (Strange Company). Все видеоролики выкладываются на сервисе Youtube. @ WikiPedia С середины апреля, а именно начиная с 18 апреля этого года, они запустили новый проект, который называется Mortal Kombat: Legacy, в котором, судя по всему, собираются для начала рассказать историю персонажей Mortal Kombat, а скорее всего и пойдут дальше, и позволят нам углубиться дальше в мир Fatality, Brutality и прочих Finish Him'ов. На данный момент ролики выходят, как и полагается правильному сериалу, раз в неделю, поэтому всего сейчас выложено три ролика. Трейлер для привлечения внимания Читать дальше →
Архитектура большинства Java(и не только) приложений сегодня предусматривает возможность расширения функционала посредством различного рода магических воздействий на код. В последнее время это также стало возможно, если использовать какой-нибудь модный фреймворк или IoC-контейнер. Но что делать, если приложение долгоживущее и слишком сложное для того, чтобы переводить его на использование какого либо фреймворка? В последнем приложении, с которым я работал, был реализован на тот момент неизвестный мне велосипед SPI механизм, который искал в джарках текстовые файлы вида META-INF/services/<qualified interface name> и брал оттуда название нужного класса, реализующего этот интерфейс, далее этот класс использовался как расширение. Поискав в интернете, узнал, что Service Provider Interface(SPI) представляет собой программный механизм для поддержки сменных компонентов и что этот механизм уже довольно давно используется в Java Runtime Environment(JRE), например в Java Database Connectivity(JDBC): ps = Service.providers(java.sql.Driver.class); try { while (ps.hasNext()) { ps.next(); } } catch (Throwable t) { // Do nothing } Благодаря этому коду приложения больше не нуждаются в конструкции Class.forName(<driver class>) (хотя и с ней будут работать), JDBC драйверы будут подгружены автоматически при первом обращении к методам класса DriverManager. SPI механизм также используется в Java Cryptography Extension(JCE), Java Naming and Directory Service(JNDI), Java API for XML Processing(JAXP), Java Business Integration(JBI), Java Sound, Java Image I/O. Как это работает? Весь смысл в разделении логики на сервис(Service) и провайдеры(Service Providers). Ссылки на провайдеры сохраняются в джарках расширений в текстовом файле(UTF-8) META-INF/services/<qualified service class>, в каждой строке полное имя класса провайдера. Пустые строки и комментарии(начинающиеся с символа #) игнорируются. Ограничения на провайдеры: они должны реализовывать интерфейс либо наследоваться от класса сервиса и иметь конструктор по умолчанию(zero-argument public constructor). Читать дальше →
Перечитав массу сопутствующей литературы и просмотрев тонну хабратопиков (ссылки на интересные приведены в конце статьи), я решил обобщить информацию об основных методах генерации надежного и запоминающегося пароля. Начну с того, что для генерации и хранения своих паролей сам я пользуюсь замечательной программой KeePass. Ее функционала вполне хватает для всех моих скромных вебмастерских нужд. Основным ее недостатком является тот факт, что она тоже требует запоминать один главный пароль. Поэтому вся эта суета вокруг придумывания пароля также касается меня и всех счастливых обладателей программы KeePass или ее аналогов, т.к. один пароль придумать все-таки придется. Поговорим о методах взлома Чтобы понимать всю глубину проблемы, пару строк посвящу методике взлома. Итак, как же злоумышленник может узнать/угадать/подобрать ваш пароль? Метод логического угадывания. Работает в системах с большим количеством пользователей. Злоумышленник пытается понять вашу логику при составлении пароля (логин+2 символа, логин наоборот, самые распространенные пароли и т.п.) и применяет эту логику ко всем пользователям. Если пользователей много, очень скоро произойдет коллизия и пароль будет угадан; Перебор по словарю. Этот вид атаки применяется, когда база данных с хешированными паролями слита с сервера. Может сочетаться с заменой букв (опечатки) или с подстановкой цифр/слов в начало или конец слова в качестве приставки или суффикса. Также используются словари, набранные в неверной раскладке клавиатуры (русские слова в английской раскладке); Перебор по таблице хешированных паролей. Передовой метод взлома паролей, когда хеши уже сгенерированы и остается только найти в базе соответствие хеша паролю. Работает очень быстро даже на слабых машинах и не оставляет никаких шансов владельцам коротких паролей. Другие методы: социотехника и социальный инжиниринг, использование keylogger'ов, снифферов, троянов и т.п. Читать дальше →
Хочу поделиться практическим опытом внедрения гибких методологий на проектах по веб-разработке высокой и средней сложности и предостеречь от коварных рисков. В большинстве простых интернет-проектов ?упрощение? классических процессов разработки работало хорошо, гибкость помогала, но в относительно больших и сложных наблюдались ?искры высокого напряжения? с частичным летальным исходом. Поехали. Гибкие и ?жесткие? Есть гибкие методологии разработки (Agile), такие как Scrum, простые и постигаемые за пару дней. А есть ?жесткие?, увесистые, требующие многомесячного погружения, такие как RUP. Гибкие методологии убеждают нас ?поверить?, что из-за того, что требования постоянно меняются, можно к черту отказаться от многолетнего опыта разработки программного обеспечения, впитанного классическими методологиями, тем же ?водопадом?, все решительно упростить и броситься в объятья ?коммунистической? свободы, честности и равенства. А чего бояться-то? Сумасшедшие бородатые специалисты говорят о процессах, артефактах, матрицах зависимости (Requirements Traceability Matrix) ? а мы в рубахе, босиком, раз и? запрограммируем любой интернет-проект за 3 спринта! Ура, товарищи, к победе. Так вот, ?упрощение?, предлагаемое гибкими методологиями, очень условное и коварное. ?Расслабились? с одной стороны, придется хорошенько поднатужиться с другой. Читать дальше →
Использование памяти в GDI В процессе переписывания диспетчера поддержки интерфейса графических устройств (GDI), Тимо Кройцер (Timo Kreuzer) столкнулся с тем, что можно назвать не иначе, как чудовищная растрата памяти. Количество выделяемой памяти для создаваемых объектов составляло всегда полную страницу, т.е. 4 Кб, вне зависимости от того, нужен ли объекту такой большой объём памяти для хранения своих атрибутов. Это приводит к значительному расходу памяти впустую, а также к расходованию адресов памяти. Тимо предполагает, что это является одной из причин, приводящих к утечке в диспетчере задач множества страниц памяти за раз. В Win32k имеется механизм кэширования таких выделений, который, по всей видимости, не использует освобожденные страницы повторно, поэтому в течение некоторого количества времени вся память системы может быть исчерпана. Читать дальше →
(Тот факт, что русского перевода понятию ?lock-free? в литературе ещё не устоялось, ? нисколько меня не убеждает, что такого перевода не должно быть.) Предположим, анализ производительности вашего приложения выявил, что существенная часть процессорного времени тратится в некой вычислительной функции, и более того, эта функция многократно вызывается с одними и теми же параметрами ? выполняя одинаковые вычисления вновь и вновь. Напрашивается простая оптимизация ? кэш из одной записи, в котором бы хранились исходные данные и результат последнего вычисления. BOOL IsPrime(int n) { static int nLast = 1; static BOOL fLastIsPrime = FALSE; // если значение параметра не изменилось с прошлого раза, // воспользуемся готовым результатом if (n == nLast) return fLastIsPrime; // вычислим и запомним новый результат nLast = n; fLastIsPrime = slow_IsPrime(n); return fLastIsPrime; } Само собой, этот код потоконебезопасен: если один поток находится внутри вызова slow_IsPrime(), то другой поток, вызвавший IsPrime(), застанет значения переменных nLast и fLastIsPrime несоответствующими одно другому. Простое решение ? заключить код в критическую секцию; но простота идёт в ущерб производительности: если, скажем, nLast = 5, fLastIsPrime = TRUE, и два потока одновременно вызывают IsPrime(5), то совершенно ни к чему им выстраиваться в очередь: ничего не мешает им одновременно воспользоваться кэшированным значением. Посмотрим, как можно реализовать наш кэш беззамочно. Читать дальше →
Отписаться от этой рассылки