На Хабре много лет назад была статья, про так называемый «пузырь фильтров» или «фильтр интересов». Смысл в том, что современные информационные системы накапливают огромные объемы данных о каждом пользователе, анализируют, структурируют и в итоге сами решают какую информацию выдавать на экран. Хорошо это или плохо? Чем это может грозить? Как это контролировать? А надо ли вообще контролировать?

Читая статьи о Photoshop, я часто удивляюсь тому, насколько многие авторы усложняют решение по сути простых задач по обработке. Этим страдают и многие «монументальные» писатели, например Дэн Маргулис. Но ему это простительно – его задача написать о всех тонкостях и нюансах процесса обработки, рассмотреть его со всех ракурсов и сторон. Хотя именно эта особенность подачи материала в его книгах отталкивает многих читателей.

На самом деле, корни подобных способов «увеличить резкость в 40 действий» растут из очень простой вещи – люди, которые пишут эти уроки, никогда не работали с большим объемом фотографий. То есть, как правило, у них есть пара фотографий и они готовы в процессе их обработки убить вечер-другой. Но когда у тебя идут постоянные заказы, и с каждой фотосессии тебе надо серьезно обработать несколько десятков кадров – начинаешь задумываться о более простых и удобных способах обработки.

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

Здравствуй, хабрасообщество! Наверное, многие из Вас с восторгом смотрят на изображения преисподней и мечтают обзавестись личной фотографией на фоне пейзажей ада, но отсутствие обратного пути в земную жизнь пугает Вас? Но что же делать, если так хочется блеснуть на фоне горящих языков пламени и искрящихся глубин ада? Предлагаю Вашему вниманию результат моих усилий и возможностей GIMPa – простой урок по превращению Вашей фотографии в настоящую адскую фотку)

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

Салют, Хабр!
Недавно я уволился с довольно завидной должности (главного архитектора) в довольно неплохой компании (Acronis) и с непоколебимым решением в мозгу больше не работать по найму переехал из Москвы обратно в Ереван, откуда семь лет назад понаехал в Златоглаво-Нерезиновую. Учитывая необычность произошедшего и часто задаваемый вопрос «но почему?!», я решил разобраться в собственных мыслях и озвучить их вслух для себя самого и тех, кто может почерпнуть в моих размышлениях что-то для себя полезное. Короче говоря, это рассказ о том, почему я оставил высокооплачиваемую перспективную работу в международной компании ради сомнительной перспективы начать собственное дело, и как я собираюсь дальше жить.

Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».

В очередной раз утратив ценный конфиг из-за перепутанных шелловых > и >>, я, наконец, понял,
что пора делать бекапы.



Можно делать копии конфигов куда-то в укромное место на диске, можно сделать rsync на удалённый сервер
или понаписать хитрых велосипедообразных скриптов.
Но самое удобное решение находится уже прямо под руками: создать git репозиторий в корне.

Много примеров начального и среднего уровней по юнит-тестированию в любом языке показывают как просто можно проверять логику Ваших приложений с помощью юнит-тестов. Однако, не все так просто бывает при тестировании приложений, в которых центральную роль играет база данных, а именно таких большинство среди веб-приложений. Те, кто занимается юнит-тестированием своих приложений, думаю, не раз сталкивались с проблемой тестирования БД. Почти 2 года назад на хабре уже была статья на эту тему, но хотелось бы ее раскрыть больше.

Всё, что написано ниже, относится к Oracle Database и Oracle Exadata.

Преамбула

Полная луна освещала пыльную, петляющую дорогу, исчезающую среди холмов впереди. Я стоял в раздумье в начале своего пути, размышляя о том, куда может привести эта дорога. Отбросив сомнения прочь, я начал свой путь к виднеющейся вдалеке пирамиде, вершина которой терялась среди облаков. По дороге мне никто не встретился, кроме памятника, больше похожего на надгробие с изображением человека и надписью огромными буквами “In Codd we trust”. Подойдя к пирамиде на достаточно близкое расстояние, я сумел разглядеть, что она состоит из DB_BLOCK-ов, большей частью размером 8Kb, но можно было найти и больше. На каждом блоке был изображен логотип компании, которая использовала блок для хранения своих данных. Заметив небольшую толпу около входа в пирамиду, я заинтересовался, и решил узнать, что это такое. Подойдя совсем близко, толпа приобрела очертания – большой частью она состояла из студентов, но встречались и бизнес-аналитики, тестеры, программисты, можно было даже заметить пару менеджеров по продажам – все они рвались внутрь.

Странное дело, порой кажется что каждый месяц появляется не меньше дюжины новых GTD-like таск-менеджеров. Одновременно с этим, хороших приложений для эффективного управления повседневными задачами крайне мало. Думаю, редкий читатель нашел для себя подходящий инструмент и пользуется им повседневно.
Мы не из ленивых, и как вы уже догадались, тоже сделали свой, с… всем что полагается.
Ниже я расскажу о нашей парадигме и особенностях, которые выгодно отличают нас от конкурентов. Т.к. многие уже устали от обилия постов о личной продуктивности на Хабре, в своем рассказе я сделаю упор на веб-технологии, а не на gtd-методологию. А пока картинка для привлечения внимания:

Далее будет говориться об Oracle Database 11g, о тех привычках что мы выработали со временем.

Самый маленький Proliant.

8 сентября компания Hewlett-Packard объявила о выходе нового продукта — самого маленького сервера в большом семействе ProLiant. Модель не имеет традиционного префикса DL/ML/..., а зовется просто HP ProLiant MicroServer.
Решение позиционируется как первый сервер для небольших структур (до 10 пользователей), соответственно цена начинается от $500.

Первые поставки только-только добрались до складов дистрибьюторов, а один из серверов уже поселился у меня дома.

Сегодня я хотел бы рассказать Вам о замечательном дополнении для Gimp'а под названием Gimpbox.

Многим уже порядком поднадоел многооконный режим Gimp'a и пока все в ожидании стабильного релиза 2.8 где разработчики обещали сделать возможность выбора между многооконным и однооконным режимом, китайские разработчики подумали как можно решить эту проблему малой кровью и сделали дополнение Gimpbox, смысл которого заключается в том что бы объединить все окна Gimp'а в одно окно как это сделано например в Adobe Photoshop, Paint.net и других редакторах.

Gimpbox является frontendом для Gimp'а, т.е. он будет работать только с уже установленным Gimp'ом.

Под катом инструкция по установки.

Не секрет, что Drupal 6.x не очень хорошо дружит с PostgreSQL. Верней ядро дружит, а вот отдельные contrib модули далеко не всегда. И вот надоело мне наблюдать периодически вываливающиеся warning'и и накладывать патчи — решил переехать на MySQL.

Google на всяческие запросы о такого рода переезде упорно выдавал миграцию в обратную сторону — MySQL to PostgreSQL, понятно почему, но не радует. Если выкинуть Drupal из контекста, то начинают находиться платные продукты и всяческие не идеальные скриптики. В итоге решил сделать все самостоятельно ручками.

Приветствую тебя хабражитель, не так давно передо мною встала задача соединить в единую сеть филиалы одной крупкой компании, разбросанные по Сибири. Главная проблема была в том, что OpenVPN надо было заставить работать поверх нестабильного PPPoE попутно пустив весь трафик через OpenVPN

Проблема

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

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

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

Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:

как называть узлы и интерфейсы узлов в сети?

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

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

node.js — серверный асинхронный Javascript, превосходный инструмент для создания серверной части COMET приложений, в частности, для игрушек, чатов, и других высоконагруженных проектов, использующий синтаксис Javascript, прекомпилируемый в машинный код, работающий на скорости, сравнимой с кодом на C++, очень быстрый, способный держать 10 — 12 тысяч подключений, и не создающий отдельного процесса/не интерпретирующий себя заново/не запускающий процесс при каждом новом клиенте. Использует в качестве основы V8 — движок Javascript от Google. Удобные возможности, можно установить значение переменной при одном посетителе, и считать это значение при ответе другому.
Обращаю внимание на то, что если вы не программировали, например, на Python или Ruby, только на PHP, не обходите его стороной, это не ещё один незнакомый язык. И в этом его преимущество — Javascript — знакомый язык, особенно для тех, кто программировал на PHP+Javascript, но PHP не позволял очень многих вещей, особенно в связке с Apache, например, аплоад файлов с полосой загрузки (без Flash), возможность низкоуровневого управления сетью (возможность написать, например, клиента или сервер Mysql или прокси-сервер вроде nginx).
О гибкости языка говорит тот факт, что расширения для работы с MySQL, например, написаны на самом Javascript.
Я планировал написать статью с описанием этой замечательной системы, с примерами, но на момент чтения читателю хорошо бы иметь под рукой установленную версию node.js. Поэтому этот пост о том, как установить node.js, в том числе и на Windows, что актуально в связи с недавним появлением порта под cygwin. (Да, есть информация о том, где скачать node.exe)

Многим разработчикам знакома ситуация когда кешировать страницы сайта, скажем, на 5-10 минут нельзя всего из-за одного небольшого блочка, актуальность которого нужно поддерживать если не в реальном времени, то с временем «старения» не больше 5-10 секунд. При этом посещаемость сайта продолжает расти, растет время генерации страниц и c этим надо что-то делать…

• Вариант решения 1: Подкрутить то, до чего не доходили руки последнее полгода. Все Вас поймут и передвинут сроки на другие задачи. Вы будете в роли «Супермена» один спасать сайт от непомерной нагрузки, решая проблему «бесплатно» (без доп. вливаний в оборудование). Вам может пригодиться статья «Тюнинг nginx».
   
• Вариант решения 2: Улучшить техническую базу (докупить мозгов на сервер, улучшить дисковую систему, поставить под БД отдельный сервер). В принципе проблема не решена, а скорее отложена. Теперь у Вас есть время «окопаться» и подготовиться ко второй волне наплыва нагрузки, она будет больше и накроет сильнее.
   
• Вариант решения 3: Ваш вариант, о котором я, вероятно, узнаю из комментариев.
   

Позвольте предложить и мне проверенное и относительно простое решение на базе одной из старейших технологий в Web-разработке.