Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель, май-июнь, июль, август.

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

Прочитав этот пост, решил поделиться и своим опытом.

В данный момент решены 2 простые задачи:

• все звонки, поступающие на PSTN номер (обычный городской), переадресовываются на мобильный телефон, который у меня всегда в кармане и, одновременно, на SIP телефон, который стоит дома
• с SIP телефона я могу звонить как по России, так и в некоторые нужные мне страны по минимальным тарифам.

Как это сделано?

Всеми любимый набор иконок — Fugue, обновился (16 июля) до версии 3.0. Изменения небольшие, были добавлены 32 гипер-маленькие иконки.

Мега-превью! (3Mb)
Иконки
Иконки + исходники

Довольно часто я наступаю на одни и те же грабли. Стараясь выполнить какой-нибудь проект побыстрее, я с головой ухожу в реализацию необходимой функциональности. А через неделю, мне на глаза обязательно попадается описание библиотеки, фреймворка или плагина, воспользовавшись которыми, я мог бы выполнить свою часть работы в разы быстрее. В общем, сейчас я стараюсь быть в курсе готовых решений в интересующих меня областях. В последнее время мне часто приходится работать с javascript и поэтому, сейчас я уделяю особое внимание библиотеке jQuery и ее плагинам. Должен сказать, что упускать из виду такое разнообразие готовых решений просто нельзя. Данная статья сделана на основе обзора «50 Awesome New jQuery Plugins», который я прочитал пару дней назад.

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

Q:

В Facebook используют MySQL зная, что он плохо масштабируется (или здесь какая-то особая магия?). Я хотел спросить, из каких соображений они выбрали MySQL? Используют ли JOIN'ы? И не планируют ли перейти на другую БД?

A:

Отвечает Adam D'Angelo, бывший CTO Facebook, сейчас он развивает свой стартап Quora:

1. Если разбивать данные по разным серверам на уровне приложения, то масштабируемость MySQL не такая уж и большая проблема. На 2008 год, в Facebook [1] у нас было 1800 MySQL серверов для которых требовалось всего два администратора. Конечно, вы не сможете сделать JOIN с данными с разных серверов, но NoSQL-базы вам тоже этого не позволят. Нет никаких данных о том, что в Facebook используют Cassandr'у как основное хранилище, и, кажется, что единственное, для чего она там нужна — это поиск по входящим сообщениям. [2]

Это перевод статьи, датированной 1м сентября 2009 года, следует это учесть при прочтении. — прим. пер.

В последний месяц или два команда инженеров Digg потратила совсем немного времени на изучение, тестирование и окончательное внедрение Cassandra в продакшен. Это был очень веcёлый проект, но до того, как веселье началось, нам пришлось потратить какое-то время на выяснение того, что же представляет собой модель данных Cassandra… фраза «WTF is a «super column»» («что за фигня этот суперстолбец?») была произнесена не один раз.

Если вы работали ранее с РСУБД (это касается почти всех), вы вероятно будете немного обескуражены некоторыми названиями при изучении модели данных Cassandra. Мне и моей команде в Digg потребовалось несколько дней обсуждений, прежде чем мы «врубились». Пару недель назад в списке рассылки разработчиков шёл процесс bikeshed-а на тему полностью новой схемы именования для разрешения неразберихи. На всём протяжении дискуссии я думал: «может, если будет несколько нормальных примеров, люди не будут так смущены названиями». Так, это моя попытка объяснения модели данных Cassandra; она предназначена для того, чтобы вы ознакомились, но не уходили в дебри, и, надеюсь, это поможет прояснить некоторые вещи.

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

Преамбула.

В связи с бурным развитием мобильных устройств и ОС Google Android в частности, интерес к разработке программного обеспечения под данную платформу весьма закономерное явление. Как оказалось, он мало чем отличается от обычной разработки на Яве под десктоп/веб, а с учетом возможности использования «стандартного» IDE (Eclipse) путем скачки и встраивания SDK Андроида, а также наличия исчерпывающей документации многие технические вопросы снимаются сами собой. Концептуальный аспект (т.е. идея для реализации в виде ПО) также не заставила себя ждать, благо платформа сравнительно новая, не смотря на недавно вышедшую уже версию 2.1, и конкурентная среда соответственно не такая насыщенная, если взять, к примеру, разработку под тот же iPhone. (Тут могла бы быть развернутая часть о самом ПО, но ввиду некоторых нюансов, таких как незаконченность проекта и отсутствие конкретных результатов, пока ее пропустим).
Оставался последний, и, естественно, самый интересный (логично, не правда ли?) вопрос – денежный, а конкретно – как правильно вывести честно заработанные дензнаки, полученные от продажи ПО на Android Market.

Вдаваться подробности не буду, все-таки статья ориентирована на тех, кто примерно ориентируется в данной теме, скажу коротко — в данном случае под прицелом оказывается сервис обработки онлайновых платежей Google Checkout, который с нерезидентами США изначально не работает. Насколько мне известно, прямых путей решения данной проблемы нет, поэтому пришлось искать обходные дорожки.

Задача прибивания футера к низу страницы обмусолена с ног до головы. Она неплохо решается для футера фиксированной высоты. А вот для случая, когда высота футера зависит от его содержимого, методов не так много. Либо это очевидное решение на javascript. Либо подгонка для этого элементов, изначально для того не предназначенных. Я, конечно, о таблицах. Хочу предложить способ, который тоже имеет свои недостатки (обо всем ниже), но недостатки эти другие, и, следовательно, может подойти тем, кому первые два не подходят.

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

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

Transmission — один из самых популярных torrent клинтов в мире Unix-подобных операционных систем и, к примеру, является выбором по умолчанию в таких дистрибутивах как Ubuntu, Fedora и openSUSE. В своей работе Transmission потребляет заметно меньше системных ресурсов нежели другие torrent клиенты благодаря чему может и используется во многих встраиваемых ОС даже таких устройств как домашние WiFi роутеры/точки доступа или сетевых медиаплеерах. Кроме того, Transmission обладает встроенным web-интерфейсом и не требует для его работы ни Apache, ни Lighttpd, ни какого другого http сервера. Именно о установке и настройке новейшей версии этого замечательного torrent клиента я и хочу рассказать в этом посте.

Продолжение набора бесплатных иконок.
42 иконки в размерах 64х64, 48х48,32х32 и 16х16
Форматы: Win, Mac OS и Png.

Иконки бесплатны для некоммерческого использования.
При коммерческом использовании иконок, пожалуйста, ставьте ссылку на pixelmixer.ru

Некоторое время назад мы представляли уважаемой публике наши open source продукты для веб-разработчиков — редактор elRTE и файловый менеджер elFinder. После анонса мы получили немало отзывов и надо сказать были изрядно удивлены, что интерес к файловому менеджеру оказался заметно выше чем к редактору.

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

И сегодня с удовольствием от хорошо сделанной работы предлагаем попробовать наше фирменное блюдо elFinder!

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

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

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

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

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

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

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

• Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
• Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
• Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback'ов, репликация работает без проблем, которые присущи RDBMS;
• Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
• Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

После написания статьи о потребностях «продажников» в CRM, я стал более плотно заниматься этой темой + на мое удивление, мне пришло много предложений от хабраколлег написать такую систему и вместе ее продавать, посмотреть на их, уже готовую CRM-ку.

Напомню, что мои основные требования были: online + удобство + малая цена

Кому интересна тема CRM применительно к небольшим компаниям — мои находки и мысли на этот счет.

Итак, что же такое CRM и кому и зачем она нужна. По сути CRM нужна не только отделу продаж, но и всем сотрудникам компании, которые связаны с работой с клиентами. В больших компаниях (телеком, банки) это такие большие системы как Oracle Siebel, MS Dynamics CRM и прочие монстры. В таких системах помимо автоматизации операционной работы (завести контакты, вести учет переговоров, выставлять счета и заводить кейсы) существует много наворотов типа BI, маркетинговых кампаний или совместной работы.

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

1. База аккаунтов (организаций) и контактов
2. Возможность быстрого доступа к ней лучше online
3. Ведение истории переговоров
4. Напоминалки (типа, через 3 месяца не забыть позвонить клиенту)
5. Ведение протоколов встреч, записи звонков, короче видеть всю историю взаимоотношений

Под катом хорошие варианты: