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

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

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

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

Инопланетяне являются почти настолько же основным столпом научной фантастики, как и межзвёздные полёты. Если задуматься, то пожалуй даже более влиятельным — Идеи о чуждой жизни обосновались в фантастике даже до межзвёздных полетов, с работами Герберта Уэллса и Эдгара Берроуза.

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


В 9 из 10 таких произведений «инопланетянин» по замыслу создателей — это типичный человек, только со странными выростами на голове, и\или неестественным цветом кожи (Наиболее хрестоматийный пример такого безобразия — сериал Star Trek). В худшем случае запредельной лени инопланетянин будет просто человеком, без каких-либо внешних отличий вообще. Это если инопланетянин подразумевается как персонаж которому можно сочувствовать, в случае если этот инопланетянин задумывается как враг, то его внешность и поведение часто больше напоминают какое-нибудь разъяренное дикое животное, чем разумное существо. Рычание или бритвенно-острые когти в полметра длиной не обязательны, но крайне приветствуются.

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

Многие из вас читали предыдущую статью про то, как неправильная визуализация для объяснения работы JOIN-ов в некоторых случаях может запутать. Круги Венна не могут полноценно проиллюстрировать некоторые моменты, например, если значения в таблице повторяются.

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

Все желающие приглашаются под кат

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

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

По долгу службы мне пришлось сталкиваться с курсорами. Хотелось бы рассказать, что это такое и о некоторых особенностях работы с ними. Официальная документация тут — dev.mysql.com/doc/refman/5.1/en/cursors.html Википедия даёт такое определение курсору курсор:

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

Также, после опубликования первых двух статей я получил пару отзывов и вопросов, связанных с проектированием БД / расстановкой индексов / составлением запросов. На многие вопросы старался отвечать. С некоторыми из них поделюсь и в этой статье.

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

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

И раньше подобный функционал был доступен, но пользоваться журналом запросов не в пример сложнее.

Итак, как пользоваться:

Радует, что все больше дизайнеров посматривают в сторону от Адоби в поисках инструментов поудобнее, полегче, попроще и подешевле. И выбирать есть что. Сегодня я расскажу про свой процесс создания дизайна сайта в Sketch.app. Надеюсь, какие-то мысли вы позаимствуете у меня, что-то никогда не станете делать так же, а до чего-то придете своим путем. Оставайтесь с нами.

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

Большинство реляционных баз данных, за исключением MS Access, состоят из двух отдельных компонентов: «back-end», где хранятся данные и «front-end» — пользовательский интерфейс для взаимодействия с данными. Этот тип конструкции достаточно умный, так как он распараллеливает двухуровневую модель программирования, которая отделяет слой данных от пользовательского интерфейса и позволяет сконцентрировать рынок ПО непосредственно на улучшении своих продуктов. Эта модель открывает двери для третьих сторон, которые создают свои приложения для взаимодействия с различными базами данных.

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

HA-Apache2 Web-Site and HA-MySQL

Цель: обеспечить высокую доступность web-приложения и минимальное время простоя при отказе одного как web-сервера, так и сервера баз данных.
Замечание! Схема предполагает, что web-приложение и база данных находится на разных серверах.
Для примера будем устанавливать wordpress.

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

В данной статье я хочу рассказать о моем опыте развертывания и использования SSRS 2008 в крупной компании. Процесс настройки и развертывания был 3 года назад, а сама система Reporting Services используется организацией уже 4 года.

В ходе проведения презентаций о бэкапах и восстановлении баз данных SQL Server, обычно задаются два типа вопросов. Первые задаются прямо по ходу презентации из зала, вторые задаются уже после, в приватной беседе. Эти, «приватные» вопросы, зачастую более интересны и я попробую дать ответы на наиболее сложные и интересные из них, вместо того чтобы писать ещё одну статью о том как вы должны делать бэкапы, или почему вы должны делать бэкапы, или даже почему вы должны проверять свои бэкапы (но вы и вправду должны проверять свои бэкапы).

Начиная с версии 5.1 в MySQL появилась такая полезная фича как партиции. Конечно же большинство разработчиков БД сразу не побрезговали ей воспользоваться. Спустя пару лет работы я наконец пожал плоды всей ущербности реализации этой технологии специалистами MySQL AB …

Начиная с версии 5.1 mySQL поддерживает горизонтальное партицирование таблиц. Что это такое? Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям.. На нижнем уровне для myISAM таблиц, это физически разные файлы, по 3 на каждую партицию (описание таблицы, файл индексов, файл данных). Для innoDB таблиц в конфигурации по умолчанию – разные пространства таблиц в файлах innoDB (не забываем, что innoDB позволяет настраивать индивидуальные хранилища на уровне баз данных или даже конкретных таблиц).

Как это выглядит?