Я уже около 20 лет программирую на Lisp и прочитал множество сообщений Usenet и статей в блогах, написанных Lisp — разработчиками. Я часто задавал себе вопрос — А существует ли типичный Lisp — разработчик, как существуют типичные представители наций или других групп людей?

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

Неоднократно в своем блоге мы останавливались на вопросах авторского права. А сегодня давайте поговорим о тех вещах, на которые оно не распространяется. Знать о них в последнее время становится все более необходимо.

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

Что такое творчество?

Хочу поділитися досвідом по темі звуку в Windows 7.
Насправді все не так погано, як спочатку здається, і я вам зараз це продемонструю.

В статье пойдет речь о Must Have тулзе для удаленной отладки Node.js приложений либо кода на WebKit браузерах node-inspector.

Для отладки кода в браузере, впринципе удаленная отладка и не нужна, не считая мобильных устройств, где она фактически не возможна потому что крайне не удобна. Совсем другое дело с серверным JavaScript. Node.js имеет несколько отладчиков, восновном продвигают ndb Node Debugger — консольная утилита для дебага Node.js приложений. Подходит только для фанатов консоли либо для мазохистов. Работать не удобно, отлаживать долго, по сравнению с отладкой кода в том же FireBug.

Что же умеет node-inspector:
1. Удаленная отладка
2. Отладка в графическом интерфейсе WebKit-debugger (На клиент ничего не нужно ставить — у вас все уже есть)
3. Редактирование runtime-кода!
4. Использует WebSockets, и никакого polling'а!
5. Удаленное профилирование блоков кода c использованием v8-profiler

Особенностью линии «вниз» сети E-UTRAN является использование технологии множественного доступа SC-FDMA (Single Carrier – Frequency Division Multiple Access) c одной несущей частотой и средней мощностью передачи PAPR (Peak-to-Average Power Ratio). Исключение взаимного влияния пользователей достигается введением циклических префиксов и использованием эффективных эквалайзеров в приемных устройствах. Интервал времени передачи TTI в линии «вверх» сети E-UTRAN соответствует TTI в линии «вниз» и равен 0.5 мс. Возможно использование увеличенного TTI для специальных типов соединений (услуг). Основная конфигурация антенн линии «вверх» при использовании MIMO предполагает использование двух передающих антенн на мобильном терминале и двух приемных антенн на базовой станции.
SC-FDMA представляет собой гибридную схему передачи, которая сочетает низкие значения PAR, присущие системам с одной несущей, таким как GSM и CDMA, с большой длительностью символа и гибким распределением частот OFDM. Принципы генерации сигнала SC-FDMA показаны на рисунке 1, который является фрагментом одного из рисунков отчета 3GPP TR 25.814 об исследовании физического уровня LTE.

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

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

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

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

Эта новость напрямую касается владельцев устройств Asus RT-N16, Asus RT-N12, Asus RT-N10, Asus WL-500gP, Asus WL-500W, D-Link DIR-320. Давным-давно не секрет, что все они (после той или иной перепрошивки) могут использоваться в качестве сервера Linux MIPS. На эту тему существует форум wl500g.info, да и на Хабрахабре мы видали отчёты и рецепты полудюжины блоггеров, которые настраивали на этом железе принт-сервер, файловый сервер с доступом по HTTP и BitTorrent, WiMAX-маршрутизатор, наращивали оперативную память и даже впаяли жёсткий диск.

Очередной шаг в этом направлении совершил фидошник по имени Александр Рыжов (2:5019/40.5), который собрал для этой же архитектуры все те свободные программы, которые входят в пакет fidoip (тот самый пакет, который я здесь упоминал в январе прошлого года в связи с появлением в нём поддержки гипертекстового Фидонета).

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

Весь необходимый софт и инструкции по его установке вы без труда найдёте в вики fidoip на SourceForge.

Аннотация

В статье рассказывается о вычислении градиента по изображению, с использованием разностных шаблонов. Предлагается очевидный и красивый способ оптимизировать последовательность: «Смаз -> Вычисление градиента». Статья является необходимой преамбулой к планируемой статье о быстрых и хитрых алгоритмах выделения контуров и углов.

Картинка из книги Thinking Forth

По мотивам «обобщенной» статьи про GOTO и статьи про GOTO в системном программировании:

Мотивы для использования GOTO и альтернативы ему принципиально отличаются для системного и прикладного программирования — это является и важной причиной холиваров. Для прояснения ситуации рассмотрим GOTO только в разрезе прикладного программирования.

Основной тезис: в прикладном программировании GOTO однозначно лучше обходить.

Как докажем:

1. В прикладном программировании критически важен один параметр кода — сопровождаемость.
2. Goto не ухудшает однозначно сопровождаемость только в небольшом проценте случаев, и даже в этих случаях принципиально от альтернатив не отличается
3. Ради небольшого процента случаев его использовать вредно:
   1) очень низкоуровневое, поэтому сильно развращает программиста (возникает соблазн использовать и в других местах) — большой вред из-за небольшого процента случаев, когда GOTO можно применить;
   2) даже в таких случаях есть более красивые альтернативы.

Многие в комментариях к посту об операторе goto высказывали одно и то же мнение, которое звучит примерно так: «За n лет написания программ мне ни разу не понадобился goto, и использовать его в будущем я тоже не собираюсь». И они абсолютно правы, уже давно доказана теорема о структурировании, в которой говорится, что любая простая программа функционально эквивалентна структурированной программе составленной с использованием функций и предикатов исходной программы, а также с использованием дополнительного счетчика. Доказательством является алгоритм составления той самой структурированной программы:

1. пронумеровать все узлы схемы, при этом порядок обхода произвольный;
2. пронумеровать все дуги схемы следующим образом: выходной дуге схемы припишем номер 0, всем остальным дугам присвоим номер вершины, в которую данная дуга входит;
3. для каждого функционального узла исходной программы, имеющего номер i и выходную дугу j, составить новую простую последовательную программу Gi с номером входной дуги i
   
4. для каждого предикатного узла с номером i составить новую простую программу
   
5. построить программу типа while do с do-частью в виде структры, проверяющей значения L.

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

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

Подход 1. Коммерческий.

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

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

Обзор практически всех *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 программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

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

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

Получить годные цифры бенчмарка это полдела, однако вторая половина их правильно интерпретировать, узнать что-то новое, и суметь применить. 100x отличия промеж дебажным и нормальным билдом удивили, решил копнуть глубже. По итогам получше узнал, что происходит в дебаге; поискал отличия между 2005 и 2008 студией (не нашел); выяснил, как ускорить дебажный билд в 3 раза за пару минут (ставим блок против удара в спину); методом «взять и запустить» получил результаты, отличающиеся от авторских в 3.5 раза (адская сила x64 в действии!); и для смеха замерил плохой, негодный недовектор против хорошего (плохой оказался до 100 раз быстрее). Подробности под катом.

Приветсвую, коллеги!

— Вы хотите запустить linuxdcpp из консоли на домашнем компьютере находясь на работе?
— Вы хотите, чтобы он запускался сразу после загрузки системы, но не желаете использовать автологон?
— На вашем сервере есть программа, которая работает только в графическом режиме, но вы не хотите держать графическую сессию пользователя всё время включенной?

Если ответ хотя бы на один из вопросов «да», то эта статья для вас.

Я ошибался дважды, выбирая работу. Совсем не от того, что неверно выбрал карьеру специалиста в сфере информационных технологий. Это очень, очень, очень интересная работа. Почти как работа капитана космического корабля… ;)

Я выбирал компании, но не выбирал боссов. И в этом состояла моя ошибка. Думаю, что не только моя…

Много слов сказано о достоинствах юнит-тестов (TDD, BDD — в данном случае неважно), а также о том, почему люди всё-таки их не используют.

Но я думаю, что одна из главных причин заключается в том, что люди не знают, с чего начать. Вот прочитал я статью про юнит-тесты, понравилось; решил, что надо бы когда-нибудь попробовать. Но что дальше? С чего начать? Как придумывать все эти требования, как называть тест-методы?

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

Об этом и пойдёт речь: