Время от времени мне приходится сталкиваться с задачами, когда нужно в рамках имеющейся СУБД выполнить соединение двух и более исторических таблиц между собой, да так, чтобы получить красивые исторические интервалы на выходе. Зачем? Чтобы отчет смог правильно отобразить данные на выбранную пользователем дату, или приложение подтянуло в себя эти данные для обработки.
Часто коллеги и братья по цеху сталкиваются с подобными задачами и советуются как лучше их решить.
В этой статье я хочу поделиться опытом как решались различные ситуации подобного типа.

Интерес к технологиям Big Data постоянно растет, а сам термин приобретает все большую популярность, многие люди хотят поговорить об этом, обсудить перспективы и возможности в этой области. Однако немногие конкретизируют — какие компании представлены на этом рынке, не описывают решения этих компаний, а также не рассказывают про методы, лежащие в основе решений Big Data. Область информационных технологий, относящихся к хранению и обработке данных, претерпела существенные изменения к настоящему моменту и представляет собой стремительно растущий рынок, а значит лакомый кусок для многих всемирно известных и небольших, только начинающих, компаний в этой сфере. У типичной крупной компании имеется несколько десятков оперативных баз данных, хранящих данные об оперативной деятельности компании (о сделках, запасах, остатках и т.п.), которые необходимы аналитикам для бизнес-анализа. Так как сложные, непредвиденные запросы могут привести к непредсказуемой нагрузке на оперативные базы данных, то запросы аналитиков к таким базам данных стараются ограничить. Кроме того, аналитикам необходимы исторические данные, а также данные из нескольких источников. Для того чтобы обеспечить аналитикам доступ к данным, компании создают и поддерживают так называемые хранилища данных, представляющие собой информационные корпоративные базы данных, предназначенные для подготовки отчетов, анализа бизнес-процессов и поддержки системы принятия решений. Хранилища данных служат также источником для оценки эффективности маркетинговых кампаний, прогнозированию, поиску новых возможных рынков и аудиторий для продажи, всевозможному анализу предыдущих периодов деятельности компаний. Как правило, хранилище данных – это предметно-ориентированная БД, строящаяся на временной основе, т.е. все изменения данных отслеживаются и регистрируются по времени, что позволяет проследить динамику событий. Также хранилища данных хранят долговременные данные — это означает, что они никогда не удаляются и не переписываются – вносятся только новые данные, это необходимо для изучения динамики изменения данных во времени. И последнее, хранилища данных, в большинстве случае, консолидированы с несколькими источниками, т.е. данные попадают в хранилище данных из нескольких источников, причем, прежде чем попасть в хранилище данных, эти данные проходят проверку на непротиворечивость и достоверность.

Недавно я прочитал статью Джоэла Спольски “Can your programming language do this?”и она настолько сильно пришлась мне по душе, что я решил перевести ее. Но не просто так, а добавить немного от себя. А именно, вместо примеров на JavaScript (использованных Джоэлем в оригинале), я решил написать примеры на С#, который мне на сегодняшний день ближе. Собственно результат и представляю на суд сообществу под катом.

С места – в карьер: в этом году слушателей Yet another Conference ждет чрезвычайно насыщенная программа, состоящая из 4 потоков и 7 секций.

Вместе с нами о технологиях, тенденциях в мире разработки и практическом опыте будут рассказывать специалисты из Microsoft Research, Cloud9 IDE, Adobe, Opera Software, Cisco Systems, Google, Spanfish, Nimbula и других компаний.
Откроют конференцию Аркадий Волож и Илья Сегалович.

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

Интернет-математика будет представлена в этом году докладами от Яндекса и Microsoft Research. Также приедет уже полюбившийся слушателям Дмитрий Мольков (exFacebook) с докладом про MapReduce. Мы поговорим про передовые алгоритмы доказательства теорем, математические модели, которые помогли Яндекс.Пробкам и многое другое.

В прошлом году все сетовали на отсутствие «облачной» секции, поэтому мы приготовили для вас несколько докладов по этой теме: про облачные вычисления и хранилища данных, особенности создания подобных платформ и технологии, которые разрабатываются внутри Яндекса. В фойе будут работать стенды партнеров – компании Nimbula из Кремниевой долины и стенд Яндекса – «Opensource Stack», где вы сможете познакомиться с Elliptics, Grape, Сocaine и Fastcgi-daemon.

В 2010 году Apache Hadoop, MapReduce и ассоциированные с ними технологии привели к распространению нового явления в сфере информационных технологий, названного «большими данными» или «Big Data». Понимание того, что из себя представляет платформа Apache Hadoop, зачем она нужна и для чего её можно использовать потихоньку проникает в умы специалистов по всему миру. Зарожденный, как идея одного человека, и быстро выросший до промышленных масштабов, Apache Hadoop стал одной из самых широко обсуждаемых платформ для распределенных вычислений, а также платформой для хранения неструктурированной или слабо структурированной информации. В этой статье я хотел бы подробнее остановиться на самой платформе Apache Hadoop и рассмотреть коммерческие реализации, предоставляемые сторонними компаниями, и их отличия от свободно распространяемой версии Apache Hadoop.

При выполнении расчетов в системах распределенных вычислений, в том числе с архитектурой MapReduce, часто возникают задачи, которые выполняются медленно или с опозданием на отдельно взятом узле (stragglers). Причиной появления таких задач может стать неоднородность кластера, hardware или software проблемы. Из-за таких запозданий падает быстродействие всей системы в целом. Создатели Hadoop стараются бороться с этим, дублируя запуски медленных задач на других узлах кластера (speculative execution), однако этот подход не позволяет определять медленные задачи своевременно.

20 сентября в московском офисе Яндекса пройдет научно-технический семинар, на котором выступит Эдуард Бортников, главный инженер исследовательского центра Yahoo!.. В первой половине своего доклада он расскажет, как решать проблему «узких мест» систем MapReduce с помощью машинного обучения. Этот метод, в отличие от технологии Hadoop, позволяет предсказывать замедление выполнения задач на конкретном узле. Предсказатель можно интегрировать с существующей системой MapReduce, таким образом увеличив эффективность системы.

Вторая часть доклада будет посвящена Sailfish – новой реализации модели MapReduce от Yahoo!.. В основе новинки лежит принцип объединения промежуточных данных и пакетная обработка операций дискового ввода-вывода. Система Sailfish блестяще прошла эксперимент на реальных данных и задачах в Yahoo!, показав поистине чемпионские результаты – эффективность выполнения задач увеличилась до 400% по сравнению с Hadoop. Кроме того, Sailfish позволяет делать автоматическую настройку параметров задачи при изменении объемов или распределения данных. Система Sailfish проще в использовании, чем Hadoop, где каждый запуск требует кропотливой, ручной настройки параметров.
Семинар пройдет на русском языке, начало в 19:00.

Для участия в семинаре необходима регистрация.

Для тех, кто не сможет прийти на семинар, будет организована видеотрансляция.

Организация Common Crawl сделала щедрый подарок разработчикам и компаниям, которые работают в области поиска и обработки информации. В открытый доступ на Amazon S3 выложен индекс из 5 миллиардов веб-страниц с метаданными, PageRank и графом гиперссылок.

Если вы видели в логах веб-сервера CCBot/1.0, то это их краулер. Некоммерческая организация Common Crawl выступает за свободу информации и поставила целью сделать общедоступный поисковый индекс, который будет доступен каждому разработчику или стартапу. Предполагается, что это приведёт к созданию целой плеяды инновационных веб-сервисов.

UICloud — это база бесплатных пользовательских интерфейсов с поисковой системой, рейтингом и каталогизатором в которой собрано все от исходников в формате PSD, до готовых решений на HTML, CSS или jQuery: формы, слайдеры, кнопки, календари, элементы и полноценные интерфейсы для мобильных и веб приложений. В проекте уже сейчас можно найти практически все что нужно для облегчения процесса разработки дизайнерам и разработчикам.

На данный момент в базе 23586 элементов и почти тысяча UI-сэтов включающие в себя готовые решения в едином стиле. Проект создан Британской студией Double-J Design целью проекта является создание самой обширной UI базы.

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

Допустим, у вас есть класс Person. Пользователи в системе могут продавать что-то и/или публиковать статьи. Подклассы здесь использовать не получится, потому что пользователь может одновременно быть и автором, и продавцом. Проведем рефакторинг.

Эта статья не для матёрых укротителей Python’а, для которых распутать этот клубок змей — детская забава, а скорее поверхностный обзор многопоточных возможностей для недавно подсевших на питон.

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

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

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

Что должно получиться

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

Демонстрация

Предисловие

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

Что это

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

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

Краткий синопсис

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



Под катом примерно 1.1 Мб трафика.

Весь поисковый индекс Google размещается в RAM памяти уже как минимум 5 лет. Почему бы не попробовать сделать то же самое и с поисковым индексом для Lucene?

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

Очевидный вопрос – не попробовать ли нам загрузить весь индекс, в предоставляемый Lucene класс RAMDirectory?

От переводчика: Это перевод заметки товарища по имени Steve Souders, который очень плотно занимается вопросами производительности веб-сайтов и даже написал пару неплохих книг на эту тему.

Вчера я проводил семинар в Google Ventures для некоторых из инвестируемых ими компаний. Я не знал насколько подготовленной в вопросах производительности будет аудитория, так что я сделал обзор вопросов, связанных с производительностью, начиная с первых моих выступлений в 2007 году. Уже несколько лет я не рассказывал о методах улучшения производительности, описаных в моем блоге "High Performance Web Sites". Я прошелся по таким вещам, как Меньше HTTP-запросов, Добавление заголовка Expires и Gzip.

Но мне надо было вернуться еще дальше. Думая о тех временах, когда еще не существовало конференции Velocity и самого понятия WPO, я решил, что должен пояснить почему я занялся именно клиентской оптимизацией. Я нашел слайды, поясняющие «Золотое правило производительности»: 80-90% времени ожидания пользователем занимает работа браузера.

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

Проводя уже около 6 лет собеседования с Java-разработчиками заметил, что из приходивших кандидатов вообще никто не знает, что можно штатными средствами JDK удалённо мониторить состояние JVM с контейнерами сервлетов.
Поэтому далее пошаговый рецепт, как настроить и использовать эту замечательную возможность

Когда я работал над сервисом заметок jotsky.com, еще до работы в Островке, надо было сделать ввод телефонного номера из двух инпутов. Примерно такой:



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

Споры о том, что лучше: ручное управление или автоматическое ведутся во многих областях науки и техники. Положиться на человека или отдаться на откуп бесстрастным механизмам и алгоритмам? Похоже, что в мире создания Enterprise решений чаша весов склонилась все-таки в сторону автоматического управления памятью, большей частью из-за того, что возиться с указателями, ручным управлением памятью и закрашивать седину после каждого бага, появившегося из-за «неправильного» компилятора С/C++ не хочется сейчас уже никому. Но до сих пор возникают на форумах топики, где не сдающиеся суровые приверженцы ручного управления памятью яростно и непримиримо отстаивают свои ретроградные взгляды в борьбе с прогрессивной частью человечества. Пусть их, оставим их в покое.

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

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

О неточностях, опечатках, ошибках пишите в личку — буду оперативно исправлять.