Два плюс два, умножить на два?

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

Цель этой статьи — помочь тем, кто рассчитывает выйти на западные рынки с продуктом или технологией, быть готовыми к тому черному дню, когда вы получите по почте иск о нарушении патентных прав. Если вы рассчитываете на успех, то наивно рассчитывать, что вас обойдет чаша сия. Не обойдет. Правда, это вряд ли будет чаша. Скорее это будет большая неотесанная дубина. Дубина патентного тролля.
Правда, такая история ожидает совсем не в каждой стране. В большинстве стран законы ограждают общество от патентования идей. Осознав, что программное обеспечение не подчиняется законам физики, а значит — запатентовать можно практически все, большинство стран существенно ограничило возможность патентования чего-либо в области ПО. Существует, однако, одно маленькое, но важное исключение — Соединенные Штаты Америки. Про эту страну мы и будем в основном говорить.
Невозможно в одной статье описать все аспекты ситуации с патентами в США. К тому же, я не американский патентный юрист, и не знаю всех тонкостей, а если бы и знал, вряд о них имело бы смысл здесь писать. Поэтому постараемся сконцентрироваться на самом важном, а если всплывут вопросы, поговорим о них в комментах.
Если тема заинтересовала, приглашаю разбираться с ней под катом.

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

Здравствуй, Хабр. Некоторое время назад мы внедрили у себя в CMS наряду с уже имевшимся к тому моменту собственным шаблонизатором, еще и XSLT. Поскольку есть в XSLT большие и реальные преимущества и для разработчиков, и для хозяев студий, и даже для владельцев сайтов. Но реакция наших партнеров разделилась на противоположные мнения: одни давно ожидали этого и были рады появлению такой возможности, другие поставили под сомнение востребованность XSLT, приводя в качестве аргумента низкую производительность, которую якобы влечет за собой использование XSLT.
Понятно, что у всего нового всегда есть сторонники и противники, и рассудит их время. Поэтому не было особого смысла развязывать религиозную войну XSLT vs tpl или Smarty на тот момент. Но мы обнаружили, что оказывается, один из лидеров российского рынка CMS с завидным упорством все пишет и пишет о якобы несостоятельности XSLT как массовой технологии и готов рассматривать ее только в контексте специфичных задач. А это негативно влияет на умы некоторых непосвященных разработчиков об XSLT.

SQL-инъекции (также известные как «Нарушение в целостности структуры SQL-запроса») являются одними из самых распространённых и наиболее опасных уязвимостей в вопросе безопасности. SQL-инъекции очень опасны, потому что они открывают двери хакерам в вашу систему через веб-интерфейс, и позволяют получить неограниченный доступ: например удалять таблицы, изменять базу данных, и даже получить доступ к внутренней корпоративной сети. SQL-инъекции это чисто программная ошибка, и не имеет ничего общего с хост-провайдером. Итак, вы занимались поисками безопасного JSP хостинга, PHP хостинга, или любого другого, вы должны знать, что за профилактику SQL-инъекций несут ответственность только разработчики, а не хост провайдер.

Почему же происходят SQL-инъекции

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

На сайте новаторского магазина thinkgeek.com столкнулся с любопытным эффектом — переливающимся фоном (чтобы увидеть конфетку нужно поработать колёсиком прокрутки). Сделан он очень просто, и все же подобная техника попалась мне впервые.

Не так давно я уже писал о программном обеспечении "Kraken", которое посредством использования специальных криптографических таблиц помогает взламывать алгоритм шифрования A5/1 (именно он массово используется операторами мобильной связи) для GSM-сетей. Но одно дело — взлом алгоритма, и другое — полная расшифровка закодированного сигнала. Вот с этим «на ура» справляется новоявленное ПО, также представленное на конференции Black Hat. Вообще говоря, эта конференция принесла много чего неожиданного, начиная от того самого Kraken-а, и заканчивая взломом банкоматов. Так вот, на этот раз эксперт по криптографии Карстен Ногл представил усовершенствованный программный пакет Airprobe. По заявлению разработчика, это программное обеспечение вкупе с несколькими компонентами позволяет максимально упростить задачу расшифровки сигналов, передаваемых по GSM-сетям (Airprobe позволяет записывать и раскодировать разговоры и SMS).

Один весьма мной уважаемый гн Ден Каминский (Dan Kaminsky — известен благодаря обнаружению им фундаментальной уязвимости в DNS ) предложил очень интересную универсальную технику защиты от SQL injection и XSS.

Метод очень просто и от того гениален.

В последнее время можно наблюдать тенденцию в отношении жалоб на службы поддержки пользователей самых разных компаний. Пользователи, недовольные качеством обслуживания, ищут защиты и пытаются найти поддержку на форумах, в социальных сетях, на хабре… Для этого они выкладывают на всеобщее обозрение переписку или даже записи телефонных разговоров с сотрудниками службы поддержки той или иной компании. Такое поведение понятно, ведь становится по меньшей мере обидно, а чаще и возмущает то, что служба поддержки совершенно отказывается работать! Хотя оплачивая услугу, программу или оборудование, мы подразумеваем, что платим не только за это, но еще и за то, чтобы с этим было как можно меньше проблем или, по крайней мере, что при возникновении проблемы — нам обязательно помогут и поддержат. Что же ожидает пользователь, когда звонит или пишет в службу поддержки? Что при этом видят работники службы поддержки? Давайте попробуем разобраться.

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

Итак, мы постепенно выходим на финишную прямую сборки Кубика Рубика 5х5х5! Осталось дособирать рёбра куба и центральные квадраты. Кроме того, есть программа-эмулятор кубика, так что даже если куба нет, можно попробовать собрать его на ПК.
Ссылка на первую часть

По просьбе гражданина dio нарисованы 25 иконок типов файлов в размерах 64х64, 48х48, 32х32 и 16х16. Иконки распространяются на условиях лицензии CC BY-ND.
Этот сет является дополнением к первому и второму бесплатным наборам.
Скачать иконки можно здесь

Создавая сайт на Biggo, есть возможность воспользоваться еще одним преимуществом SaaS — учет индексации сайта поисковыми роботами. Обычные JS-счетчики или счетчики на основе картинки, конечно, не дают такой возможности. В liveinternet есть возможность учитывать запросы поисковых ботов, но она там дается «в догонку», в разделе экспресс-аудит. К тому же, для того, чтобы этот отчет заработал необходимо установить предлагаемый PHP-код.

Наша система независимо собирает данные для создания этого нужного для вебмастеров и оптимизаторов отчета и отображает результаты в виде красивых интерактивных графиков

Круговая диаграмма, отражающая доли разных поисковых роботов

Потребовалось однажды реализовать пейджер постраничной навигации а-ля дёти.
Далеко в лес ходить я не стал, а решил найти, что же это за зверь такой раскопированный на множестве сайтов, а оказалось, что это детище karaboz. И даже есть аналог, переделанный под jQuery.

Но у каждой версии есть, как мне показалось, огромный недостаток, игнорирование колесика мыши. «Но ведь с этим было бы удобнее!» — воскликнул я и решил немного переписать, чтобы пейджер прокручивался на событие mousewheel. А также есть другие недостатки, которые я освещу под катом.

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

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

Так давайте же начнем с самого контракта.

Фиксированная цена, время и объем обязательств

Такие контракты фиксируют сразу три магических фактора — деньги, время и объем обязательств. Являются ли цена и сроки проблемой для agile команд? Ну, не должны быть. На самом деле, таймбоксинг (timeboxing) — это обычная практика. Ограничение бюджета только помогает таймбоксингу лучше работать.

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

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

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

Перевод статьи Тима Ферриса из его блога.


(Учебник Дзюдо Окано Исао, который я использовал для изучения японской грамматики)

Изучение языка не должно быть сложным.

Принципы когнитивной нейронауки и управления временем могут быть применены для достижения свободного владения языком на разговорном уровне (в данном случае определяется как 95%+ процентов понимания и 100% выразительных возможностей) в течение 1-3 месяцев.

Поднявшаяся в этом топике дискуссия о криптостойкости многократного применения хеша над паролем (проскальзывавшая, кстати, и в других форумах), подтолкнула меня к этому немного математическому топику. Суть проблемы возникает из идеи многократной (1.000 и более раз) обработки пароля перед хранением каким-либо криптостойким алгоритмом (чаще всего хеш-функцией) с целью получить медленный алгоритм проверки, тем самым эффективно противостоящий brute force-у в случае перехвата или кражи злоумышленником этого значения. Как совершенно верно отметили хабрапользователи Scratch (автор первой статьи), mrThe и IlyaPodkopaev, идея не нова и ею пользуются разработчики оборудования Cisco, архиватора RAR и многие другие. Но, поскольку хеширование – операция сжимающая множество значений, возникает вполне закономерный вопрос – а не навредим ли мы стойкости системы? Попытка дать ответ на этот вопрос –

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

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

Для тех, кто не читал предыдущие части: I часть про идеи и II часть про пилот