Читать топики с иллюстрациями приятнее. Они кажутся более понятными и интересными. Но на Хабре вставка картинок в топики организована неудобно: вместо картинки нужно иметь URL.

Народ по-разному борется с этим недостатком: кто заливает файлы на свой FTP, кто пользуется онлайновыми хранилищами фоток вроде Picasa или Flicr. Но это долго и неудобно. Предлагаю более удобный вариант.

Год назад учёные из Google произвели революцию в эпидемиологии, когда определили паттерн поисковых запросов, который характерен для инфицированного гриппом человека (научная работа в PDF). Соответственно, путём анализа всего объёма поисковых запросов оказалось возможным с высокой точностью предсказывать эпидемию гриппа примерно за две недели до её начала. Так появился сервис Google Flu Trends.

В научно-исследовательских лабораториях Google решили не останавливаться на достигнутом. Если мы можем предсказать эпидемию гриппа по поисковым запросам, то предсказать движение фондовых индексов вообще легко, решили они, написали ещё одну научную работу (PDF) и запустили на сайте Google Finance новую фичу Google Domestic Trends, предназначенную специально для инвесторов.

Идея в том, что поисковые запросы являются опережающим индикатором для фондового рынка, также как они являются опережающим индикатором для эпидемии гриппа. Эти явления (сильное движение рынка и вирусная эпидемия) вообще похожи друг на друга по многим признакам.

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

Однажды на моём нетбуке (Acer Aspire One 110) я не смог нормально посмотреть видео по причине тормозов (аниме в 720p). После чего последовало разбирательство на тему, как же это можно исправить, результат которого читайте здесь.

Внимание!

Сия статья ориентирована на людей которые по тем или инным причинам являются владельцами смартфонов на базе Symbian OS, но не смотря на это используют свой девайс исключительно для вскрытия пивных пробок звонков. В статье присутствуют элементы пренебрежения авторскими правами некоторых забугорных софт контор, но учитывая мои исключительно благие намерения я позволю себе такую слабость. В конце концов, если захотите приобрести ту или инную софтину — вас никто не держит. У меня, например, около 30% софта чесно куплено (ибо я в нем действительно нуждаюсь), 60% — свободнораспространяемого, и всего лишь 10% — вареза, платить за который я отказываюсь принципиально, в силу несоответствия цены и качества у онного.

Я, при содействии и снабжении меня необходимым запасом провианта и очень стимулирующими (правда, очень) пинками со стороны моего незабвенного товарища которого зовут Олегом, пишу статью-мануал, такую себе азбуку начинающего смартовода, которая поможет ему (смартоводу) разобраться в азах смартовединея и достойно заюзать сии прекрасные девайсы как на то полагается по праву. С чего это вдруг? Хе-хе… В один прекрасный день я узрел своего старого знакомого. Он такой себе среднестатистический писи пользователь, кодит даже немного на питоне (джаст фор фан)… Так вот, попросил он меня помочь ему освоить новый гаджет (который он виду врожденной паталогической лени не захотел осваивать с Божей и (или) Гугла помощью). Ну помог я человеку ес-но, как уж тут отказать-то. И задумался. А ведь сколько народу имеют в своем распоряжении смартфон, но в виду лени/отсутсвия времени даже не желают им пользоваться. Может и среди хабранарода есть такие? Вот в сегодняшней статье я расскажу вам о том, как из безжизненного куска железа на безе Symbian OS сделать то, чем не стыдно и даже приятно пользоваться.

Очень часто приходилось слышать такое от людей, которые много времени проводят за администрированием и другими IT-забавами.

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

Совсем недавно где-то на Хабре промелькнуло высказывание из серии «Не думал, что консоль в Виндах что-то может. Хотелось бы узнать об этом побольше».

Вот так и возникло желание написать небольшую статью про основные возможности консоли.

Описание игры на Хабре

Продолжение и, скорее всего, окончание моего исследования про графы из текстов.
Мне подсказали страницу, где есть реализация одного алгоритма (QuickSort) на разных языках программирования, а значит есть отличная возможность сравнить графы этих «одинаковых» программ.
Под катом полученные графы для языков: C, C++, Java, Visual Basic, Delphi, Python, Php, Prolog, Fortran, Ruby, Haskell, Algol, Mathematica, Asm.
Попробуйте не заглядывая под кат угадать, какой граф будет наиболее красивым и какой самым страшным?

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

Надеюсь, что пост будет полезен людям которые знакомы с лямбдами C++, но хотят изучить блоки Objective-C и наоборот.
Здесь я постарался описать синтаксис замыканий, механизмы захвата контекста, управление памятью и взаимодествие лямбд и блоков между собой.
Во всех примерах использовался Apple LLVM Compiler 4.2 (Clang). Для приведенного Obj-C кода не используется ARC, т.к я придерживаюсь мнения, что необходимо знать как работает non-ARC код, чтобы понять как работает ARC.

Начал изучать NodeJS. Нигде не нашел актуальный стек мейнстримных библиотек (технологий) применяемых в node. Поэтому решил сам составить список.

Введение

На хабре уже несколько раз упоминали о проекте Meteor, основанном в 2011 году семерыми энтузиастами web-технологий из Сан-Франциско. По сути Meteor является просто надстройкой над node.js, который сам ещё даже не дошёл до релизной версии. Тем не менее проект собрал более семи тысяч подписчиков на github и получил 11 миллионов долларов инвестиций.
С чего такая популярность? Дело в заявлении авторов о том, что они хотят кардинально переосмыслить способ написания современных web-приложений в сторону его упрощения. Не секрет, что написание кода на чистом node.js довольно сильно выворачивает мозг и вынуждает использовать различные костыли в виде control flow средств. На Meteor, говорят авторы, писать крутые приложения сможет даже гуманитарий.
Ну что же, проверим. Имеется: 1 гуманитарий-социолог, закрывший сессию и желающий после Парсонса и Зиммеля перейти на что-нибудь полегче, компьютер с Ubuntu 12.10 и установленный node.js (не спрашивайте, как он оказался у социолога).

Вдохновимся обещаниями разработчиков, прекрасной девушкой-членом команды и начнём.

Всем привет!

Я активный пользователь open-source фрэймворка Grab (itforge уже писал о нем здесь и здесь) и 1/2 проекта GrabLab (который занимается собственно коммерческой эксплуатацией фрэймворка). Т.к. парсим сайты мы часто, помногу и задания как правило совершенно не похожи друг на друга, хотелось бы поделится своим опытом в вопросе построения типичного парсинг проекта.

Немного про инструментарий который помогает мне в работе

В качестве рабочего браузера я использую FireFox с плагинами HttpFox (анализировать входящий/исходящий http трафик), XPather (позволяет проверять xpath выражения), SQLite Manager (просмотр sqlite таблиц), код набираю в emacs, где активно использую сниппеты (YASnippets) для часто встречающихся конструкций.

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

Привет, хабрасообщество!

В этой теме я хочу обсудить наиболее правильное использование компонента CGridView в Yii.
Ниже я опишу 3 способа, которые вижу лично я, и буду рад услышать ваши идеи в комментариях.



Итак, задача:
Требуется страница с несколькими блоками, в одном из которых должна быть таблица (грид).
Нужна возможность сортировки и постраничной навигации грида через ajax.

Звучит несложно, не правда ли? Давайте посмотрим, что нам предлагает Yii.

Раньше я был ярым поклонником Smarty. У Smarty достаточно много достоинств, он распространен, с ним просто, он привычен и так далее. Но так вышло, что для одного из проектов Smarty оказался слишком уж тяжелым и слегка тормозным. Я не говорю, что Smarty плох или что он негодный, нет. Просто в некоторых условиях его производительность оказалась недостаточной, и надо было искать альтернативу. Альтернатива нашлась и я очень рад, что мне выпала возможность работать с Twig.

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

Мы будем следить за твоими успехами, юный Скайуокер.
(с) канцлер Палпатин.

В статье рассматриваются 3 сайта для мониторинга рейтинга/статистики AppStore, которыми я чаще всего пользуюсь. Дана краткая характеристика каждому ресурсу.
Эта статья может быть полезна:

• раработчикам программ для iДевайсов (как начинающим, так и не очень)
• маркетологам
• всем, кто следит за бурным ростом мобильного IT вообще и AppStore в частности.

Основным источником информации о динамике продаж приложений в AppStore, безусловно, является iTunesConnect. Однако, как только приложений становитьься 2 и больше, там возникают некоторые сложности. Более того, естественно, iTunes совершенно не подходит для анализа успехов конкурентов, с чем рано или поздно приходится сталкиваться каждому разработчику.

Наиболее часто использую

В данной статье я расскажу об одном из способов, позволяющих с наименьшими усилиями трансформировать программный код на C/C++ в код, написанный на C#. Впрочем, рассказанные принципы подойдут и для других пар языков. Хочу сразу оговориться, что способ не рассчитан на трансформацию кода, реализующего GUI.

Для чего это делать? К примеру, я таким образом портировал известную графическую библиотеку LibTiff (и LibJpeg заодно) на C#. Это позволило использовать наработки многих людей, создававших LibTiff, в моей программе вместе с библиотекой классов .NET Framework. Примеры кода в статье будут в основном из LibTiff и LibJpeg.

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

Буквально несколько часов назад, после внимательного изучения комментариев вот к этому топику я был несколько удивлен что многие не очень любят использовать условия HAVING и похоже другие возможности СУБД. Скажу прямо — мне очень понравилась обсуждение простейшего и не работающего запроса, в результате которого многие узнали для себя много нового и познавательного (это мое личное мнение). Поэтому я решил сделать вот что — вывести три моих самых любимых задачи по знанию SQL (MySQL) на суд общественности.

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

Продолжая тематику Многомерные кубы, OLAP и MDX и olap для маленькой компании, традиционно, предлагаю начать с простенького «Hello World» куба, который будет анализировать процессы и тенденции голосований на Хабре.

Итак, давайте попробуем создать свою первую OLAP систему.
Но, прежде чем, потирая руки, запускать Business Intelligence Studio, предлагаю вначале создать хранилище данных хабра-голосов, так называемый Data Warehouse.
Зачем? Причин в этом несколько:

• сама суть Data Warehouse-а хранить «очищенные» данные, готовые для анализа, поэтому даже его изначальная структура может сильно отличаться от структуры нашей хабра-OLTP базы данных
• в HabraDW (так мы его назовем) мы вынесем только ту информацию, которая нам нужна будет для анализа, ничего лишнего
• к Data Warehouse не накладываются требования нормализации. Даже наоборот, денормализировав некоторые данные можно добиться более понятной схемы для построения куба, а также скорости загрузки данных в куб