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

Последнее время на Хабре зачастили статьи про обработку естественного языка.
И так уж совпало, что последнее время я работаю в этой области.
Был очень хорошо освещен sentiment analysis, и теггер частей речи pymorphy.
Но мне хотелось бы рассказать, какие средства для NLP использовал я, и что я нашел нового, чего здесь еще не было

Широко известны сайты для решения олимпиадных задач по программированию, такие, как, например, TopCoder и Codeforces, а также сборники математических задач-головоломок, например, Project Euler. За последний год произошёл бум онлайн образования: возникли стартапы Coursera и Udacity, предоставляющие онлайн курсы от топовых университетов США… но для тех, кто хочет изучить биоинформатику, пока ничего нет.

Розалинд — проект, разрабатываемый в Санкт-Петербуге и University of California, San Diego с мая 2012 года, как раз заполняет эту нишу. Это платформа для обучения биоинформатике с помощью решения задач, бесплатная и открытая.

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

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

По задумке, к каждому участнику процесса формирования учебного плана (например заведующему кафедры) привязывается агент, являющийся помощником и консультантом. В качестве инструмента, позволяющего легко реализовать таких агентов и обработать их поведение, была выбрана платформа JADE (Java Agent Development Framework).

Расскажу вам как я использую интерактивную консоль Jython для ускорения разработки Bean'ов в поддерживаемом мной приложении.

Суть вопроса

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

По долгу службы пришлось поддерживаю очень древнее приложение с громадной кодовой базой. Хуже всего то, что оно собирается оно от минуты до семи и ещё минуты три стартует. Опять же каждому программисту не сложно представить себе какой ад написать энное количество кода, а затем ловить NullPointerException'ы от внешних сервисов с таким длинным циклом Implement->Compile->Start Deploy->Wait->Smoke->Wait->Test.

Возможен также другой вариант. Есть энное количество кода в классе, который нужно адаптировать под выполнение задачи, близкой уже им выполняемой. А теперь представьте, что этот класс реализован в рамках Java 1.4. Он не работает с Generic'ами, потому что они были добавлены только в Java 1.5. Кроме того программисты, ранее занимавшиеся поддержкой системы, этим активно пользуются и суют в коллекции возвращаемые методами других классов, что не попадя вплоть до анонимных реализаций java.lang.Object.

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

RabbitMQ позволяет взаимодействовать различным программам при помощи протокола AMQP. RabbitMQ является отличным решением для построения SOA (сервис-ориентированной архитектуры) и распределением отложенных ресурсоемких задач.

Под катом перевод первого из шести уроков официального сайта. Примеры на python, но его знание вовсе не обязательно. Аналогичные примеру программы можно воспроизвести практически на любом популярном ЯП. [так выглядят комментарии переводчика, т.е. меня]

Давно я собирался купить какой-нибуть универсальный радиоприемник/радиосканер, чтобы полазить по эфиру, послушать о чем говорят ночью матёрые и бородатые радиолюбители…

До недавнего времени, это удовольствие обходилось от 300$ и до бесконечности. Ну а с переходом гос.органов (и России и за бугром) на цифровую (но пока еще не зашифрованную) связь APCO P25 стоимость удовлетворения нездорового любопытства стала ещё выше.

Год назад все изменилось — умельцы выяснили, что многие из продающихся у нас китайских USB TV-тюнеров за 600 рублей — фактически являются универсальным радиоприёмником, на который без каких-либо доработок можно послушать практически все-что угодно в диапазоне 50-900Мгц (если повезет — до 2200Мгц, но там голосом особо ничего не передают): переговоры самолётов с диспетчерами, строителей, такси, жучки в вашей квартире и многое другое.

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

Нашел как-то на stack overflow вопрос (link).
Need to create java CLI programm that searchs for specific files matched some pattern. Need to use multi-threading approach without using util.concurrent package and to provide good performance on parallel controllers.
Перевод
Нужно написать консольную программу, которая ищет файлы по какому-то паттерну. Программа должна быть многопоточная, но нельзя использовать пакет util.concurrent. Требуется добиться максимальной производительности.


В общем идея в принципе была не сложная. Т.к. по условию нельзя использовать util.concurrent, то надо реализовать свой пул потоков, плюс написать какие-то таски, которые в этом пуле потоков будут крутиться.
Так же я не был уверен в том, что при многопоточном использовании IO будет увеличение производительности.

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 памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

Первая часть — вводная.
Вторая часть — быстрый старт.

Третья часть — тонкости и особенности.

(от 27 июля 2012)
При написании нативного веб-приложения легко начать чувствовать себя богом, способным работать просто с библиотекой работы с DOM (такой как jQuery) и горсткой сервисных плагинов. Вскоре возникает проблема в виде груды вложенных возвратных функций jQuery и разбросанных DOM-элементов без всякой структуры вместо приложения.

Короче, мы застреваем в спагетти-коде. К счастью, есть современные JS-фреймворки (библиотеки, задающие, кроме функций, правила организации кода --прим. перев.), помогающие поддерживать структуру и организованность в проекте, облегчающие ремонтопригодность в будущем.

■ Что такое MVC или, лучше сказать, MV*?

Эти современные библиотеки дают разработчикам простой путь к организации кода, используя вариации паттерна проектирования, известного как MVC (Model-View-Controller). MVC разделяет задачи в приложении на 3 части:

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

В октябре я уже рассказывала о способах оценки тестирования, все страждующие и сочувствующие могут посмотреть запись здесь. А сегодня мне захотелось затронуть тему метрик проекта в целом, причём метрик не «длягалочных», а метрик «пользуприносящих» и «проектыулучшающих». Именно поэтому, вместо сухих формул и перечня метрик, я расскажу 3 истории из опыта о внедрении и использовании строго определённых метрик в строго определённых условиях — и о результатах, которые с их помощью удалось достичь.

Зачем что-либо измерять?

Есть проект. Ваш любимый, родной, которому вы желаете расти и процветать.
Но как вы оцените его процветание, если нет критериев этого самого процветания?
Как вы сможете оперативно среагировать на проблемы до того, как они стали неисправимыми, если не будете использовать «датчик грядущей Ж»?
Как вы поймёте, что именно следует улучшать, если вам неизвестен источник проблем?

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

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

А если не приходят, значит метрику можно смело выбросить ;)

В прошлой статье я описал, как мы в Иннове используем data mining для предсказания ухода новичков, только начинающих свой путь в ММОРПГ Aion, на основе логов их действий за пару часов или дней, проведенных в игре. Но у нас также есть и ветераны, посвятившие игре месяцы и годы, и они тоже иногда уходят. Мы уже научились с высокой точностью предсказывать угасание их интереса теми же методами data mining.

Введение

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



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

Сравнение с точки зрения разработчика

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

Привет Хабрачеловеки!

После затяжной паузы, я попробую продолжить визуализировать структуры данных в Java. В предыдущих статьях были замечены: ArrayList, LinkedList, HashMap. Сегодня заглянем внутрь к LinkedHashMap.



Из названия можно догадаться что данная структура является симбиозом связанных списков и хэш-мапов. Действительно, LinkedHashMap расширяет класс HashMap и реализует интерфейс Map, но что же в нем такого от связанных списков? Давайте будем разбираться.

После появления статей типа "Я не знаю ООП" — возникает желание внести ясность, «сорвать покровы» и «докопаться до истины».

Принципы объектно-ориентированности

Обычно выделяют (читай: на собеседовании требуют назвать) четыре «принципа объектно-ориентированного программирования»: абстракцию, инкапсуляцию, наследование и полиморфизм.

На мой взгляд (не говоря о том, что абстракция и полиморфизм могут быть запросто отнесены к подразделам наследования), принцип тут один, в общем, тот же самый, что при проектировании баз данных: представление всего в виде объекта — некоторой штуковины со свойствами. Набор обычно бывает фиксированным, и тогда говорят о классе объектов, а даже если понятия класса и нет, то наличие свойств с определёнными названиями подразумевается логикой программы, т.е. нечто типа класса в виде некоего минимального набора свойств всё равно присутствует. В общем, воззрения восходят к давнему С-шному/паскалевскому типу данных struct/record. Потом к этому добавили немного «функциональности» (в смысле функционального программирования): значением свойства может быть функция, причём такая, которая имеет доступ к самой структуре/записи, значением одного из свойств которой она является. Сей феномен, в лучших традициях немецкого латиноязычного нейминга (когда опция называется «вариантом», а степень числа — «потенцией»), назвали «методом». Желание повторно использовать код, в сочетании с представлением каждого предмета как некоего подобия паскалевской «записи», привело к появлению концепции «наследования».

Всем привет!
Сегодня я расскажу тебе, %USERNAME%, о башмаках и сургуче, капусте, королях координатах, проекциях, геодезических системах и совсем чуть-чуть о веб-картографии. Устраивайся поудобнее.

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

Вот, казалось бы, простая вещь — географические координаты. Широта и долгота, что может быть проще. А вот представьте, что вы очутились на необитаемом острове. Смартфон утонул, а других средств связи у вас нет. Остаётся только написать письмо с просьбой о помощи и по старинке выбросить его в море в запечатанной бутылке.

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

Красивая идея продукта в рамках крупной компании или стартапа почти всегда неизбежно сталкивается с рядом сложностей на этапе воплощения. Частенько бывает, что работа идет, баги фиксятся, релиз приближается, но общего понимания состояния продукта нет как нет. Так бывает потому, что собственная гениальность создателей софта или сервиса (особенно если речь идет о стартапах) застит им глаза, и проблемы продукта понимаются неадекватно. Как результат — в лучшем случае команда не попадает в сроки релиза, а в худшем – на свет появляется нежизнеспособный продукт, который пользователи презрительно называют альфой и шлют создателям лучи ненависти через форму обратной связи.

Капитан Очевидность намекает: чтобы такого не допустить, важно уметь понимать, в каком состоянии находится ваш продукт на каждом этапе его развития. В этой большой статье предлагается методика оценки его состояния в самой наглядной форме – в форме таблиц и графиков. Здесь обобщен мой опыт и опыт всей команды новосибирского офиса Parallels за последние шесть лет. Чтобы было понятно: мы делаем Parallels Plesk Panel – хостинг-панель, которая используется примерно на каждом втором сервере в мире, предоставляющем услуги веб-хостинга. Применив эту методику, мы получили вот такие результаты:

1. существенно улучшилось качество выпускаемых релизов (согласно Incident rate);
2. релизы стали более предсказуемыми, точность наших прогнозов и оценок выросла в разы;
3. появилось понимание, почему что-то идёт не так и как этого избежать в будущем.

Заинтересованных лиц прошу под кат и в комменты. Отвечу на любые вопросы.