Здравствуйте.

В контексте анализа данных из твиттера возникла задача обработки хештегов. Нужно было взять хештег и разбить его на отдельные слова (#habratopic => habra topic). Задача казалась примитивной, но, получается, я ее недооценил. Пришлось перебрать несколько алгоритмов пока не было найдено то, что надо.

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

Вчера стало известно о том, что поисковый гигант выпустил финальную версию языка программирования Go 1, анонс о котором появился в 2009 году. Загрузить бинарные дистрибутивы языка для Linux, FreeBSD, Mac OS и Windows можно здесь. Язык выпущен под лицензией BSD.

Язык Go1, согласно команде его разработки, представляет из себя «попытку объединить скорость разработки динамических языков, таких как Python, с производительностью и безопасностью компилируемых языков, таких как C или C++» Справедливости ради, один из инженеров Google, занимающихся новым языком, признаёт, что экосистема языка ещё развита недостаточно — отсутствует IDE и набор поставляемых библиотек не очень большой, но, тем не менее, компания активно работает над улучшением ситуации.

Доброго времени суток!

Несколько дней назад, гуляя по интернету, я наткнулся на достаточно интересную подборку сайтов, которые следуют, если можно так сказать, практике под названием Responsive Web Design. В двух словах, эта практика подуразумевает создание «резинового» сайта, который будет тянуться в зависимости от размера окна вашего браузера, или же экрана вашего мобильного телефона. Итак, встречайте наших сегодняшних героев!

Предисловие

Есть у нашей компании своя собственная CRM и периодически в эту систему добавляются данные о неких организациях с точным адресом, и главное что адреса эти по сути уникальны, то есть в системе не должно быть нескольких организаций по одному адресу (специфика, на самом деле могут, но контролируется челфаком*). С недавнего времени в систему был прикручен КЛАДР, но и он не мог быть панацеей, т.к. КЛАДР имеет кучу неточностей, многие нас. пункты остались без номеров домов итд. итп., хотя адреса эти в реальности есть (данные предоставляют сотрудники компании и они достоверны). В общем ввод адреса оставили в свободной форме с подсказкой из КЛАДр. Сразу хочу сказать, что от комбинации полей мы отказались, т.к. многообразие аббревиатур сокращений не сулило ничего хорошего, к тому же вполне позволительным был адрес на подобии («Ололошское ш. 5км», «ТЦ Весельчак У» или даже «Центральный рынок»). И наконец главный враг программиста — челfuck, подразумевающий от неграмотности и опечаток до залипающей клавиатуры и опечаток. Остальное под катом…

Здравствуйте!

Недавно появилась необходимость сделать простое иерархическое дерево для web страницы (структура организации). Блоки получились неплохие, но когда пришло время соединить все стрелками, возник вопрос – как? Решение было два: рисовать стрелки в .png или же использовать спецсимволы.

Но хотелось чего-то более быстрого, удобного, современного – т.е. просто указать: стрелка от блока А к блоку Б. Уже к вечеру была написана небольшая библиотека, позволяющая реализовывать задуманное…

Начнём с описания ifttt.com

ifttt.com — это очень перспективный стартап, который в двух словах: Lets You Hack Together Web Apps, Without Coding Skills. Если детальнее, то это сервис позволяющий пользователям, без погружения в API огромного количества сервисов и каких либо знаний о разработке\языках программирования смешивать и автоматизировать различную активность друг с другом. В начале 2012 года получили посевные инвестиции в размере $1.5M.

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


Экран задач выглядит так

В мире ИБ существует целая куча конференций, посвященных техническим и не очень проблемам ИБ. Если говорить о США, то, определенно, все знают о таких монстрах, как BlackHat и Defcon. В Европе тоже полно конференций, среди которых я бы выделил HackInTheBox, тот же BlackHat, а также иные небольшие, локальные, но это не значит, что плохие – Chaos Communication Congress, CONFidence, DeepSec, BruCon, PH-Neutral. Мне удалось побывать на европейской части BlackHat, о чем, собственно, и пишу.

Аннотация

Эта статья будет интересна тем, кто продвигает свои собственные программные продукты в интернете. Статья исключительно практическая. Она представляет собой отчёт о некоторых действиях, которые мы осуществляли в последнее время для продвижения продукта PVS-Studio. Я расскажу, что работает, что не работает и поделюсь сопутствующими мыслями.

В любой профессии есть тонкая прослойка людей, которые являются действительно высококлассными специалистами. Не исключение и область фронт-енд разработки — здесь также есть выдающиеся личности. К их мнению прислушиваются, за ними следят в блогах и социальных сетях и читают их книги. В процессе своей работы они рождают различные оригинальные решения или техники, которые мгновенно расходятся по миру веб-разработки и остаются актуальными не один год. Они создают удобные онлайн-сервисы для верстки, пишут полезные js-библиотеки, совершенствуют браузеры, пропагандируют веб-стандарты и оказывают непосредственное влияние на их развитие. Они могут называть себя front end engineer, front-end developer, web developer, web designer, UI Designer, browser compatibility expert или просто css lover, но для большинства из нас они — звезды мирового фронт-енда, которые делают интернет таким, каким мы его знаем. На Хабре довольно часто появляются обзоры интересных решений, техник и новостей из мира веб-разработки с указанием западных авторов, однако далеко не все знают что-нибудь о них кроме имени. Мне захотелось вкратце рассказать для широкой публики о некоторых из этих товарищей.

Здравствуйте, уважаемые хабражители. Постов про пользовательские скрипты (userscripts) было на хабре немало, тем не менее, они только показывали, как ими пользоваться. А в работе юзерскриптов достаточно много кроссбраузерных несовместимостей (как и в любой области браузерного js). Естественно, можно установить различные дополнения для разных браузеров, однако, в случае написание скрипта для конечного пользователя, придётся сопровождать его огромным readme по установке компонент для обеспечения нормальной его работы. Что лично меня, да и вас, полагаю, тоже, не очень-то устраивает.

В данной статье речь будет вестись о трёх браузерах: Mozilla Firefox (с установленным GreaseMonkey), Google Chrome, Opera. Целью статьи является «заготовка», которая позволит пользовательскому скрипту работать одинаковым образом во всех перечисленных браузерах. Реализация GM API рассматриваться не будет, т.к. таковых уже сотни. Предполагается, что читатель уже знаком с общими правилами написания юзерскриптов (в случае, если нет, рекомендую сначала прочитать другую статью).

Есть отличная идея! Вы стали счастливым обладателем мозгов, которые придумали совершенно новый, никем не разработанный сервис, который покорит интернет как twitter или facebook. Однако есть, что называется, две большие разницы между инновационным сервисом и успешным стартапом. Запускать любую неведомую фигню следует с приложением всей интеллектуальной мощи организма и за пределом его физических сил.

Собственно, что и как запускать, чтобы не разориться и не провалиться?

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

Итак, встречайте — Evernote Offline (лучшего названия пока не придумал)

Давно хотел написать на данную тему, но создавая топик, подвис минуты на две, пытаясь понять, куда его запихнуть (в какую тему). В итоге запихнул в программирование, но тема актуальна вообще для всего хабра в целом. Речь идет о глазах.

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

Приступим.

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

Бегло просматривая новый стандарт C++11, решил углубить свое понимание в теме rvalue references. Все, в принципе, замечательно, но есть подводные камни, а именно: некоторая потеря обратной совместимости с С++03.

Фильтр Калмана — это, наверное, самый популярный алгоритм фильтрации, используемый во многих областях науки и техники. Благодаря своей простоте и эффективности его можно встретить в GPS-приемниках, обработчиках показаний датчиков, при реализации систем управления и т.д.

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

В поисках готового велосипеда для решения задачи мониторинга за изменениями в ФС с поддержкой linux+freebsd наткнулся на приятную python либу watchdog (github, packages.python.org). Которая помимо интересных мне ОС поддерживает также MacOS (есть своя специфика) и Windows.
Тем, кому данный вопрос интересен и кого не отпугнет индийское происхождение автора, прошу

С развитием браузерных MVC-фреймворков, Rails очень часто стали упоминать в контексте удобного фреймворка для REST-провайдеров. Мы тоже используем Rails для этой цели и достаточно долго. Есть, однако, очень большая проблема: представления. Вьюшки, которые описывают структуру JSON для ответа.

На первый взгляд, все просто отлично. Ничего кроме .to_json или RABL, в некоторых сложных случаях, не требуется. Но затем ситуация выходи из под контроля. И идут бесконечные циклы перебора JSON-билдеров в поисках лучшей жизни.

Проблема

Давайте возьмем для примера банковский сервис. Он состоит из 30 моделей. Каждая модель представлена CRUD-реурсом (в каждом по 3-4 расширяющих метода). В каждой модели 10-12 полей и это обычно длинные строки. И, конечно, все они связаны. Вплоть до 4-5 уровней belongs_to.

При этом важно помнить, что в реальной жизни JSON ответа – это не просто прямой дамп структуры модели. В нем постоянно встречаются условия (какой атрибут должен попасть в ответ? Зависит от другого атрибута) и кастомные методы.

Проблема представлений заключается в том, что клиенту REST-сервиса нужен уникальный набор полей модели для каждой такой модели и _для каждого метода_ этого REST-ресурса. И не забудьте про вложенные сущности.

HTML документ загруженный в browser есть дерево DOM элементов и набор CSS правил. Каждое CSS правило это пара — селектор (selector) и список свойств (list of properties).

Мы мало задумываемся над тем, а собственно чего стоит нарисовать HTML документ c вычислительной точки зрения? Знания про то что думатель — думает, а неонка у нея унутре ярко светит сквозь opacity:0.5 элементы бывает явно не достаточно.

Собственно про это и есть данные статьи — про вычислительную сложность (computational complexity) отображения HTML и CSS. Хочу отметить что я использую свой собственный опыт имплементации HTML/CSS rendering engines (HTMLayout и Sciter), но вычислительные проблемы в данной области универсальны — определяются самой природой HTML и CSS спецификаций.

Признак того, что объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция».

Каждый раз когда из написанного класса вы создаёте всего один экземпляр, используете только раз и тут же выбрасываете, следует думать: «ой, надо бы это отрефакторить! Можно сделать проще, намного проще!»

Перевод доклада Джэка Дидриха, одного из ключевых разработчиков языка Питон. Доклад прозвучал 9 марта 2012 на конференции PyCon US.