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

Доброго времени суток!
Данная статья описывает мой опыт построения отказоустойчивого почтового сервиса Microsoft Exchange 2010 SP1.
Она полезна по большей части новичкам для того, чтобы разобраться в теории.
Я не буду углубляться в практические аспекты, а постараюсь изложить теоретическую базу, необходимую при построении отказоустойчивого кластера Exchange.
Все остальное – под катом. (Много текста!)

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

Вместо вступления

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

Здравствуйте,

Хочу поделиться опытом и рассказать о некоторых нюансах.
Для начала немного информации о самой Google Merchant (далее GM). Это сервис от Гугл, в некотором роде — каталог продуктов всяких разных категорий, который позволяет покупателям искать товары, а продавцам, соответственно — выставлять их на показ.
Продукты (информация о них), загруженные в сервис, могут быть использованы в поиске товаров (Google Product Search) рекламе (Google Product Ads, т.е. можно связывать рекламные сообщения сразу с товаром) и при прокладке инфраструктуры (Google Commerce Search).

Хотелось бы коснуться проблемы выбора программного обеспечения для тех, кто сам не управляет проектами, а является начальником руководителей проектов по разработки ПО. Например, это может быть руководитель проектного офиса или руководитель департамента разработки программного обеспечения (или как там оно может называться). В общем – это человек, которые сам напрямую не управляет проектами, но должен помогать это делать другим. Что такому начальнику хочется знать:

• Чем заняты сотрудники? Т.е. в каких проектах участвуют и когда освободятся.
• Кто будет делать новые проекты?
• Кого попросить заняться неожиданно возникшей проблемой (найти и исправить критическую ошибку, возникшую в самый неподходящий момент; поехать к заказчику, чтобы реанимировать упавшую систему; сопроводить сейла для решения технических вопросов с потенциальным заказчиком и т.п.).
• Ну и, наконец, когда всё остальное хорошо, просто интересно, а как там дела с проектами?

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

• Полнофункциональные программы управления проектами.
• Программы управления несколькими проектами.

Рассмотрим их подробнее.

Для корректной работы многих rails-приложении требуются конкретные версии состовляющих компонент, таких как версия ruby, версия самого rails, а так же rake, rubygems и т.д. И скорее всего в вашем дистрибутиве Linux (в моём случае это Ubuntu 10.04 LTS Server) версии этих компонент будут отличаться. Можно пойти простым путём — поставить ruby нужной версии из исходных кодов, а всё остальное с помощьью rubygems. Но мы же хотим получить надёжный и воспроизводимый результат, а систему, при этом не превратить в свалку.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

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

Давно хотел потрогать руками Глонасс, но до недавнего времени цена встраиваемых модулей с поддержкой Глонасс была совершенно неприличной, как и их доступность. Волей случая, оказался у меня инженерный образец Глонасс+GPS модуля Геос-3 (он выходит в серийное производство в марте-апреле 2012г.), и моими результатами работы с ним я и хотел бы поделиться.

Зачем нужен Глонасс, если и GPS работает нормально? Справа как раз такой пример. При 23 спутниках выше горизонта, в окно видно только 3, 1 GPS и 2 GLONASS. В таких условиях каким бы крутым GPS приёмник ни был, он не сможет определить координаты вообще, а для комбинированного GPS+Глонасс приемника тут фатальных проблем нет.

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

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

Подавляющее большинство из нас использует такое крайне полезное устройство, как источник бесперебойного питания. Качество питания не везде идеальное, да и просто мельчайшие проблемы с электропитанием иногда могут дорогого стоить. Потери данных это всегда неприятно, а иногда просто таки фатально. Устройство куплено, установлено под стол, подключено и владелец его находится в полной уверенности, что в любом случае при перебое в электропитании он успеет корректно завершить работу, а может быть и сделать бэкап на флешку. Время идет, бесперебойник периодически дает о себе знать — как заправский сторожевой пес он подает голос при малейших отклонениях в параметрах электросети. Хозяин спокоен и все хорошо. Но в один из дней перебой таки случается и в этот раз ИБП не просто подает голос и сразу переключается с батареи на сеть, в этот раз свет выключили на долго. Мы спокойно копируем файлы (ведь в запасе у нас минут 15, не меньше) и тут бесперебойник начинает пищать совсем часто и все выключается. Как так? Ведь бесперебойник же должен был нас защитить от подобных ситуаций, а он только вселял нам ложную уверенность в нашей безопасности! Почему так произошло?

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

Проблема _непрочтения_ ТЗ встает практически каждый раз, когда "написатели" ТЗ и разработчики — люди из разных контор.

Этот пост — о Техническом Задании на разработку интерфейсов [для пользователей].

Разработчики – такие же люди, как и все. Читать талмуд об интерфейсе, написанный канцелярским языком – наверняка не очень приятное времяпровождение. Специалисты по интерфейсам разрабатывают ТЗ и передают их Заказчикам. И просят прочитать техническое задание (или спецификацию) – о том, как разрабатывать и изменять спроектированный интерфейс.

Что включает в себя техническое задание для разработки спроектированного интерфейса?

Доброго времени суток!

Предисловие

Когда-то я хотел познакомиться с Rails поближе, но не знал с чего начать, пока мне на глаза не попалась эта статья. Далее вы увидите перевод, смешанный с собственным опытом и свойственными мне лексическими и фразеологическими оборотами. Итак, поехали.

Введение

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

Однако, изучение Ruby on Rails является достаточно простым занятием. Это невероятно мощный фреймворк, который имеет огромное сообщество, продвигающее его вперёд. Итак, у нас возникает вопрос: какой способ изучить Rails является лучшим? Вот он — план занятий.

Каждый программист оказывается в ситуации, когда ему необходимо изучить какую-либо новую технологию или же фреймворк. Если в вашем ToDo листе в графе «Изучить» есть такой компонент, как jQuery, то данный курс для вас.
Курс состоит из 30 видео уроков, длительность каждого из них составляет 15 минут. Чтобы зарегистрироваться на курсе, вам необходимо оставить свой e-mail на странице Learn jQuery in 30 days.

На данный момент в курсе присутствуют следующие темы:

1. DOM Traversal
2. Events
3. DOM Manipulation
4. Effects
5. AJAX
6. Plugin Development

Присоединитесь к 30942 студентам, которые хотят изучить jQuery.

Как подсказывает alphard, курс можно скачать с rutracker'а.

TheSortableTree — гем, реализующий функционал Drag&Drop для деревьев построенных на основе гемов awesome_nested_set или nested_set.



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

Мы использовали гем для формирования многоуровневого дерева комментариев. Но было одно но… В тот момент не было ни одного хелпера, который бы позволял отрисовывать эти деревья. Из-за этого приходилось выдумывать свои велосипеды. Свой велосипед сделал и я.

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

Да, меня критиковали — это медленно отрисовывается, это не сработает на дереве из 10 000 элементов, надо по-другому и вообще…

Однако с 2008 года я так и не увидел чего-то другого, более доступного, быстрого и простого. Возможно, я плохо искал.

И вот я, потупив взор и нервно теребя в руках носовой платочек, представляю вам реинкарнацию моего хелпера в виде гема основанного на Rails Engines.

Уверен, для отрисовки небольших деревьев (до 100 элементов) и создания небольших CMS, где хочется управлять деревом простым перетаскиванием, мой хелпер подойдет идеально.

https://github.com/the-teacher/the_sortable_tree

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

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

Дисклеймер

Может показаться, что в этом топике я ругаю Яндекс, но на самом деле все совсем не так. Эта история о том, как мелочи могут серьезно повлиять на впечатление от продукта, или помочь в решении проблемы. Также, я надеюсь, что эта статья поможет «собратьям по несчастью» пока в Яндексе занимаются доработками продукта.

Предыстория

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

Добрый день Хабр,

Хочу познакомить пользователей Хабра с проектом над которым работает наша небольшая команда. Axis — это CMS для создания интернет магазинов под открытой лицензией.

Репозиторий на GitHub: http://github.com/axis/axiscommerce
Сайт: http://axiscommerce.com

Маленькое предисловие. У нас возникла необходимость сделать сайт. И не просто визитку, а интернет-магазин с нестандартной системой заказа. Точнее – переделать существующий, но так как существующий в плане безопасности и удобства администрирования (а еще и дизайну и качеству верски) не годился никуда, нужно было делать заново.
Побеседовав с рядом программистов (сама таковым н являюсь) мы поняли, что CMS (даже модифицированная) нам не подходит, самописный код – отпадает по ряду причин (нет гарантии безопасности прежде всего), нужен сайт на фреймворке.
Почему было не обратиться за сайтом к готовой команде, где есть менеджер и проверенные сотрудники?

Во-первых, уже был опыт работы на фриланс биржах, стаж 2 года, аккаунт работодателя с 20+ отзывами…все казалось реальным, учитывая то, что я сама могу сверстать (правда что-то совсем простенькое), установить на хостинг – словом, обладаю базовыми знаниями и опытом общения со специалистами.

Во-вторых – хотелось себя попробовать в новой должности, это ж карьерный и личностный рост…а как звучит – «менеджер проекта»!

В-третьих — честно, хотелось сэкономить. Бюджет проекта составлял около 2500$ (+-), и возникло предположение, которое тогда казалось очевидным – зачем платить больше, если лучше мы за эти деньги наймем не просто хорошего, а очень хорошего дизайнера…? Это касалось и других участников проекта.
На проверке все оказалось не таким очевидным, зато появились базовые принципы, которые хочется изложить в статье, а так же получить дополнения – возможно, у того, кто был или является менеджером проекта тоже они сложились – таким образом коллективный разум образует интересную тему и, возможно дискуссии, в которых, как известно, рождается истина.

Все написанное – личное мнение, обязательно стоит это учесть.

Качества, необходимые менеджеру проекта

1) Стрессоустойчивость.