Недавно у меня возникла необходимость соорудить некое подобие видеонаблюдения. Требования были довольно простые:

• возможность наблюдать через интернет
• не обязателен режим реального времени, достаточно вечером просмотреть основные события за день (скажем, узнать, сидит ли кто-нибудь за вашим любимым компом, пока вы на работе)
• отсутствие необходимости тратить часы на отсмотр результатов
• максимально возможное качество картинки
• минимальная стоимость

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

В противовес готовым решениям, самоделка на Raspberry Pi – это достаточно недорого, куда более увлекательно, и гораздо более гибко, благодаря полноценной ОС на борту и терабайтам готового софта на любой вкус.

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

(с) xkcd

Без использования сложных формул и матлаба я постараюсь ответить на следующие вопросы:

• FT, DTF, DTFT — в чем отличия и как совершенно разные казалось бы формулы дают столь концептуально похожие результаты?
• Как правильно интерпретировать результаты быстрого преобразования Фурье (FFT)
• Что делать если дан сигнал из 179 сэмплов а БПФ требует на вход последовательность по длине равную степени двойки
• Почему при попытке получить с помощью Фурье спектр синусоиды вместо ожидаемой одиночной “палки” на графике вылезает странная загогулина и что с этим можно сделать
• Зачем перед АЦП и после ЦАП ставят аналоговые фильтры
• Можно ли оцифровать АЦП сигнал с частотой выше половины частоты дискретизации (школьный ответ неверен, правильный ответ — можно)
• Как по цифровой последовательности восстанавливают исходный сигнал

Я буду исходить из предположения что читатель понимает что такое интеграл, комплексное число (а так же его модуль и аргумент), свертка функций, плюс хотя бы “на пальцах” представляет себе что такое дельта-функция Дирака. Не знаете — не беда, прочитайте вышеприведенные ссылки. Под “произведением функций” в данном тексте я везде буду понимать “поточечное умножение”

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

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

Знаки препинания — неотъемлемая часть любого языка. Обычная запятая может кардинально изменить значение предложения: достаточно вспомнить историю с «Казнить нельзя помиловать». А работа переводчиков и редакторов предполагает, что они свободно ориентируются как минимум в двух пунктуационных системах.

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

Вступительное слово

Считается, что «киллер фичей» СКВ Git является легковесное ветвление. Я ощутил это преимущество в полной мере, ведь я перешел на Git с SVN, где ветвление было достаточно дорогим процессом: для создания ветки нужно было скопировать весь рабочий каталог. В Git все проще: создание ветки подразумевает лишь создание нового указателя на определенный коммит в папке .git/refs/heads, который является файлом с 40 байтами текста, хешем коммита.

Основными командами пользовательского уровня для ветвления в Git являются git-branch, git-checkout, git-rebase, git-log и, конечно же, git-merge. Для себя я считаю git-merge зоной наибольшей ответственности, точкой огромной магической энергии и больших возможностей. Но это достаточно сложная команда, и даже достаточно длительный опыт работы с Git порой бывает недостаточным для освоение всех ее тонкостей и умения применить ее наиболее эффективно в какой-либо нестандартной ситуации.

Попробуем же разобраться в тонкостях git-merge и приручить эту великую магию.

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

Прим: странно, что этой заметки нет на хабре. Я решил исправить это недоразумение.

Программирование — сложная штука, но много принципов, которые делают программиста лучше, почти не отличаются от того, чему нас учили воспитательницы.

Вдохновением для списка ниже послужило эссе “Все что мне действительно нужно знать, я узнал в детском саду”, автор Robert Fulghum (http://www.robertfulghum.com/).

1. Делись со всеми

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

Прыдстория. В одной производственной компании было около двух десятков(!) кадровых баз. Это базы обособленных подразделений, и в каждой по несколько сотен человек. Всего около 10 тысяч сотрудников. Системный администратор работает грамотный, есть рабочая MS Active Directory.

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

Параллельно админ понял ещё одну страшную вещь: в компании по факту работает примерно в три раза меньше людей, чем учёток у него в системе. Почему? Да всё просто: учётки заводились по письменным заявкам, а при увольнениях и переводах обновлять статус зачастую забывали.

В этот момент мы начали работать над внедрением общего решения по управлению учетными записями и правами доступа, IdM. Для начала пришлось избавиться от раздробленности и свести все кадровые базы в одну промежуточную кадровую систему. Её связали с Active Directory через новый центр-репозиторий. Потом подключили к репозиторию остальные бизнес-системы вот так:



Дальше мы удалили все лишние учётки, оставили только действительных сотрудников (заодно увидели пару уволенных, но активно логинящихся). Потом нашли пару очень странных людей…

Недавно друг притащил ко мне простенький игрушечный вертолёт:



Управляется он не по радио, а посредством инфракрасных сигналов. На самом вертолёте стоит обычный ДУ-приёмник, а значит используется несущая частота в 36-40кГц, и не составит труда разобраться в структуре сигналов, которые посылает пульт, чем я и решил заняться.

Сразу скажу, что вся эта затея изначально не имела никакого смысла, это просто статья о том, как развлекаются айтишники :)

Присылает нам заказчик (Газпром) свою версию договора.
Понимаем — нашу они не подпишут,
вносим реквизиты и отправляем обратно.
Пропадают на две недели… возвращают протокол разногласий к договору.

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

Все чаще приходится слышать: "Работай на результат!"

"Работай на результат!" — кричит начальник подчиненному, чтобы заставить этого тупого неповоротливого кретина, принятого в команду по протекции, приносить хоть какую-то пользу общему делу.

"Мы работаем на результат!" — бахвалится бригада голодных гастарбайтеров, надеясь, что, если они будут кричать именно это, их предложение хотя бы немного выделится среди гула голосов тысяч голодных и безработных.

"Обязательна ориентированность на результат!" — напишет пожилая кадровичка «ГорАвиаВагонМорСтроя» в требования к кандидату на должность помощника бухгалтера, будучи уверенной в том, что раз все так пишут, то и ей надо.

"Наш девиз — Работа на Результат!" — именно так, с двумя Большими Буквами для большего пафоса пишет на корпоративном сайте очередной говноконторы-однодневки молоденькая девочка-всё-в-одном, гордо именующая себя помощником руководителя по связям с общественностью. И этот самый руководитель, даже не знающий, что секретутка это, оказывается, ни больше ни меньше, целый его помощник, тоже употребит эту фразу на фуршете в городской администрации с целью создать себе рекламу в среде местных бюрократов.

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



А хуже ли?

Мы, программисты, — оптимисты. Это проявляется во всем цикле разработки ПО от оценки сроков до написания кода и внедрения. Как показывает моя практика, в разработке ПО законы Мерфи работают в 100% случаев. Несмотря на это, я раз за разом сталкиваюсь с «программистами-оптимистами».

Топ «оптимистичных» допущений:

Вольный перевод статьи Якуба Линовски — «A Good User Interface».

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

Статье 14 лет. Но, что удивительно, перевода этой классики на Хабре нет. Значит, будет.

Итак, вы называете себя «проектировщиком интерфейсов»? Если не сможете на все вопросы ответить быстро и обоснованно — вон из профессии!

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

А если вы не знаете, что такое «закон Фиттса», просто пройдите тест, не подсматривая в ответы. Это прояснит, какими стереотипами вы руководствовались. В ответах — подробный разбор задействованных принципов, и вы можете сравнить свои стереотипы с моими ответами. И не пугайтесь плохих результатов: большинство людей, даже давно знакомых с компьютерами, в первый раз проходит тест очень плохо. Зато во второй раз ответы получаются правильные, и большинство считает эту статью самой ценной на моём сайте: одно её прочтение улучшит все интерфейсы, спроектированные в дальнейшем.

Эти вопросы предполагают, что всё экранное пространство под вашим полным контролем. Просто представьте себе, что вы главный дизайнер в Microsoft или Apple.

По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?

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

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

Чем доступнее информация, тем больше её вокруг. Чем быстрее она распространяется, тем меньше остаётся времени на то, чтобы её проверить. Постепенно информационная среда превращается в некое подобие «белого шума». Всё труднее строить внутри себя новые информационные фильтры, чтобы отсеять лишнее: убрать в сторону лозунги, агитацию, пропаганду, а оставить только то, что на самом деле кроется за ними. А манипулировать нашими мыслями пытаются постоянно, и я говорю не о 25-ом кадре (он не работает), а о более земных вещах — приёмах пропаганды, которые так умело (а зачастую — очень топорно) используют политики, рекламщики и вообще, все, кому не лень. Об этих приёмах и пойдёт речь в статье.

Хвост виляет собакой. ("Wag the dog") — чтобы избежать большого скандала или «замять», оставить незамеченным какое-нибудь важное, но неприятное событие, часто используется простой, но хитрый и ловкий приём, который англоязычные политтехнологи называют «Wag the dog», а русскоязычные — «Хвост виляет собакой». Он заключается в том, чтобы вовремя поднять волну обсуждения вокруг вопроса второстепенной важности, на фоне которой другое, более важное событие или действие пройдёт незаметно.
Примеры таких вопросов: Отмена перехода на зимнее время, российское гражданство Депардье, поездка Путина или Саши Грей на Ладе Калине по России, полёты со стерхами и т.д.
Своё название этот приём получил в честь английского выражения tail wagging the dog, который, в свою очередь, появился из следующего народного пассажа:

— Почему собака виляет хвостом?
— Потому, что собака умнее, чем хвост. Если бы хвост был умнее, он вилял бы собакой.

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

В качестве shell-оболочки рассмотрим bash, как самую используемую. А в качестве операции над файлами рассмотрим удаление, как самую деструктивную.

В комментариях Хабра упоминались вопросы по использованию представлений. Данный топик является обзором представлений, появившихся в MySQL версии 5.0. В нем рассмотрены вопросы создания, преимущества и ограничения представлений.

Что такое представление?

Представление (VIEW) — объект базы данных, являющийся результатом выполнения запроса к базе данных, определенного с помощью оператора SELECT, в момент обращения к представлению.

Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.

В CSS 2.1 появилась одна интересная фича, о которой не все знают — это возможность задавать на веб-странице шрифты и цвета, которые используются в текущей системной теме операционной системы.
Это может быть полезно в ситуациях, когда вы хотите приблизить интерфейс вашей страницы к пользовательскому интерфейсу операционной системы. Например, вы хотите написать Adobe AIR приложение, или сделать справочный интерфейс, наподобие нативной chm-справки (вот как здесь: manual.pohape.ru).

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

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

Сложно в двух словах описать тематику статей — она, как я сказал, очень широка. Поэтому ниже просто приведу несколько тем, которые сохранил в закладки.

С давних времен многих смущает разнообразие вариантов обеспечения безопасности при выполнении операций с максимальными привилегиями. Например, в официальной документации Ubuntu в качестве команды редактирования рекомендуется использовать что-то вроде sudo nano, а в многочисленных любительских мануалах (в стиле «5 фокусов в командной строке, которые удивят вашу бабушку») для получения root'ового шелла предлагается писать sudo su -. Попробую объяснить, почему такое положение вещей кажется мне неправильным.