Итак, мы приходим на работу и, вуаля, через 40 минут назначено совещание (митинг). Тема «Обсудить решение текущих проблем», продолжительность 1 час, в списке приглашенных 8 человек. 40 минут томительного ожидания и мы на месте — здороваемся с коллегами, настраиваемся на конструктивный лад. Появляется организатор, бодренько стартует и… уже через пять минут мы понимаем, что в очередной раз теряем время. Вроде бы, и обсуждаемые проблемы вполне реальны, и присутствует достаточно людей, но совещание неуклонно превращается в бесцельную дискуссию.

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

Год назад я уже публиковал бестселлер "Как не надо публиковать деловые письма". И вот, очевидно, пришла пора для сиквела: сегодня в моей хабрапочте случился ремейк шоу под названием «Предложение, от которого нельзя отказаться-2».

За прошедшее время подросла новая поросль эффективных менеджеров, предприимчивых стартаперов и прочих халявщиков всех мастей — они освоили новые приёмы, хитрые ходы и совсем растеряли чувство меры.

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

Привет, к делу

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

Например, сейчас мне нужна помощь в создании контента для проекта типа ***, но только для рунета.

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

Введение

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

Основные операции в деревьях выполняются за время пропорциональное его высоте. Сбалансированные деревья минимизируют свою высоту (к примеру, высота бинарного сбалансированного дерева с n узлами равна log n). Большинство знакомо с такими сбалансированными деревьями, как «красно-черное дерево», «AVL-дерево», «Декартово дерево», поэтому не будем углубляться.

В чем же проблема этих стандартных деревьев поиска? Рассмотрим огромную базу данных, представленную в виде одного из упомянутых деревьев. Очевидно, что мы не можем хранить всё это дерево в оперативной памяти => в ней храним лишь часть информации, остальное же хранится на стороннем носителе (допустим, на жестком диске, скорость доступа к которому гораздо медленнее). Такие деревья как красно-черное или Декартово будут требовать от нас log n обращений к стороннему носителю. При больших n это очень много. Как раз эту проблему и призваны решить B-деревья!

B-деревья также представляют собой сбалансированные деревья, поэтому время выполнения стандартных операций в них пропорционально высоте. Но, в отличие от остальных деревьев, они созданы специально для эффективной работы с дисковой памятью (в предыдущем примере – сторонним носителем), а точнее — они минимизируют обращения типа ввода-вывода.

Про взлом паролей windows было написано немало статей, но все они сводились к использованию какого-либо софта, либо поверхностно описывали способы шифрования LM и NT, и совсем поверхностно описывали syskey. Я попытаюсь исправить этот неодостаток, описав все подробности о том где находятся пароли, в каком виде, и как их преобразует утилита syskey.

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

С удивлением обнаружил, что про явление алиасинга (aliasing) здесь постов нет. Ситуацию нужно исправить, тк. алиасинг в любой сколько-то сложной C++ программе обязательно хоть где-нибудь, да есть. Это может быть хорошо, давая возможность ловких оптимизаций, а может быть плохо, внося повышенной паршивости баги. Под катом вкратце про оба случая (ну и неизменное «компилятор бьет спина», конечно; для разнообразия сегодня это gcc).

Небольшая прелюдия

Приветствую хабрасообщество.

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

Вступление

Итак к сути происходящего. Исходим мы из того, что у нас имеется домен с авторизацией в любой LDAP-совместимой службе каталогов (далее СК). И желание с возможностью создать файловый сервер на основе Linux+Samba (можно на той же машине что и СК). Зачем каждому выделять личную папку? В основном для хранения данных на сервере так, что бы ни кто не имел к ним доступ. Почему каждому своя папка, а не 1 каталог с разграничением прав? Да действительно существует и такой способ, для меня как админа, они примерно равны по геморойностисложности реализации, но для юзеров однозначно выбранный подход удобнее.

Рассказывать о настройке непосредственно samba с авторизацией в ADСК я здесь не буду, об этом и так куча статей в рунете и не только, остановимся лишь на паре значимых для нас параметров. В основном речь пойдет о shell скрипте, который и упростит все наши задачи до невозможности.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

Наткнулся на Stackoverflow.com на интересный топик с вопросом о новом в программистском жаргоне. Предлагаю здесь подборку наиболее интересных выражений.

Египетские операторные скобки

if (a == b) {<br>  printf("hello");<br>}<br><br>

Сей пост навеян неожиданным для меня интересом хабранаселения к посту уважаемого Milfgard из Мосигры про производство в Китае. Дело в том, что один из моих интересов как раз в производстве батарей – Denaq. И производство расположено ну конечно же в Китае. Я не стану рассказывать про организацию производства, там свои замечательные фокусы есть. Я расскажу именно про заказ чего-то под себя и покупку всякого опта. Что-то вроде алгоритма украшенного реальными историями из личного опыта. Это все будет про электронику, так как я сам именно ею занимаюсь. Истории и иллюстрации я буду выделять курсивом. Кому скучно читать общие выводы – читайте только их.

Почитать описание других паттернов.

Пожалуй, начнем.
Для начала, поясню несколько организационных вопросов.

• Описание того или иного паттерна, является моей сугубо личной интерпретацией теоретического и практического материала, собранного из книг и интернет-статей;
• При построении UML-диаграмм, я буду использовать свободный редактор от компании astah, ввиду его простоты и независимости от конкретного языка или среды. При этом, диаграммы не будут отличатся изобилием картинок и цветов, но будут ясно отображать суть паттерна;
• При реализации практических примеров, язык программирования будет выбираться совершенно случайно. Однако, я буду стараться подбирать те языковые средства, на которых данный паттерн реализуется не тривиально;
• Каждый мой пост, будет содержать как минимум 5 секций — Проблема, Описание патерна, Практическая задача, Диаграмма классов и Реализация;
• Если Вы, с чем-то не согласны или у Вас есть дополнения к материалу, изложенному мной — я буду рад их почитать в комментариях. Однако, помните — я тоже изучаю паттерны вместе с Вами :)

Почитать описание других паттернов.

Проблема

Предоставить клиенту единообразный доступ к листовым и составным элементам древовидной структуры.

Описание

Существует большое количество программных систем, в которых так или иначе применяются древовидные структуры объектов. В большинстве случаев, это всевозможные конструкторы/редакторы, которые позволяют собрать что-то большое (составное) из чего-то более мелкого (листового). При этом, клиент трактует и большое и мелкое как одно и тоже, а система должна различать составные и листовые объекты соответственно.

Почитать описание других паттернов.

Проблема

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

Описание

Для более детального понимания проблемы, рассмотрим конкретную ситуацию. Пусть имеется некоторый объект — «кнопка», принадлежащий классу объектов «Кнопка», на который понадобилось возложить дополнительные обязанности. Под обязанностями, в данном контексте, понимаются какие-либо особенности поведения объекта. В случае с кнопкой, можно рассмотреть поведение объекта при его отображении на экране. При этом, будем считать, дополнительными обязанностями — отображение рамки кнопки, надписи, иконки. Важно понимать, что все эти обязанности должны иметь возможность быть наложенными как одновременно, так и по отдельности. Очевидно, первое, что приходит на ум — порождение классов (механизм наследования). Для данной задачи возможно это и выход — расширить класс «Кнопка» семью (2³-1 = 7) различными классами, сочетающими в себе всевозможные комбинации обязанностей. Это классы: «Кнопка_С_Надписью», «Кнопка_С_Рамкой», «Кнопка_С_Иконкой», «Кнопка_С_Надписью_И_Иконкой», «Кнопка_С Рамкой_И_Иконкой», «Кнопка_С_Надписью_И_Рамкой», «Кнопка_С_Надписью_И_Рамкой_И_Иконкой». А если таких обязанностей будет не три, а хотя бы десять, не говоря уже про неудобство работы с подобной структурой. Безусловно, порождение классов в таком случае — заведомо проигрышный вариант. Однако, из этой ситуации есть выход — паттерн «Декоратор».

Почитать описание других паттернов.

Проблема

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

Описание

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

Таким образом, минимизация зависимости подсистем, а также снижение объема передаваемой между ними информации — одна из основных задач проектирования.

Один из способов решения данной задачи — использование паттерна «Фасад».

Почитать описание других паттернов.

Проблема

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

Описание

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

Почитать описание других паттернов.

Проблема

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

Описание

При проектировании сложных систем, достаточно часто возникает необходимость обеспечить контролируемый доступ к определенным объектам системы. Мотивацией для этого служит ряд приобретаемых преимуществ. Таких как, ленивая инициализация по требованию для «громоздких» объектов, подсчет количества ссылок на объект и т.д. и т.п. Однако, не всегда потребность в контролируемом доступе к объекту базируется только на преимуществах. Как правило, сложность процессов реального мира, ограничения вычислительных ресурсов просто не оставляют проектировщику выбора, нежели как воспользоваться паттерном «Заместитель» («Сурогат»).

Почитать описание других паттернов.

Проблема

Эффективно и компактно реализовать механизм обработки потока событий/запросов/сообщений в системах с потенциально большим количеством обработчиков.

Описание

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

Так сложилось, что я много раз рассказывал о том, что такое SaaS и что в нем хорошего, как на различных it-конференциях, так и в кулуарных беседах, но до сего момента писать по теме не приходилось. При этом модель SaaS во-первых для меня по сути родная, учитывая сферу деятельности, а во-вторых является одним из основных трендов в современных веб-технологиях. В связи с этим, хочу поговорить о SaaS, как о таковом, а в перспектике, если окажется интересным, о частных аспектах. По сути материал о базисных вещах, но именно такого понимания многим не хватает. А о сложном надо хотя бы пытаться говорить просто. Помогает.

Сразу хочу сказать одну вещь, SaaS — это специализированный термин и, если начинать в нем копаться, сложный. Он может навести не только тоску, но и определенный благоговейный ужас. Но на самом деле штука это простая. Чтобы пользоваться каким-то SaaS-продуктом, в том числе нашим, понимать глубинный, да даже и поверхностный смысл данного термина совершенно не обязательно. Более того, когда uCoz создавался, никто из самих разработчиков даже не слышал подобного слова. Просто появлялись продукты, имеющие по своей сути общую модель, и потом ее стали как-то классифицировать, выделять особенности, плюсы, минусы.
Если своим призванием или увлечением вы сделали веб-технологии, или же задумываетесь о том, какой тип продуктов лично для вас подходит более всего, какие наиболее перспективны и т.п., все это может быть интересно и полезно.

С ростом популярности web-приложения его поддержка неизбежно начинает требовать всё больших и больших ресурсов. Первое время с нагрузкой можно (и, несомненно, нужно) бороться путём оптимизации алгоритмов и/или архитектуры самого приложения. Однако, что делать, если всё, что можно было оптимизировать, уже оптимизировано, а приложение всё равно не справляется с нагрузкой?