Константин Китманов

Создать элемент SCRIPT с нужным SRC и вставить в страницу.

У Кевина МакЛеода много музыки: incompetech.com/m/c/royalty-free/
Распространяется под CC Attribution (CC-BY).

Это фича и о ней описано в мане linux.die.net/man/1/bash

Смысл в том, что ~/.bash_profile читается при login, а ~/.bashrc при интерактивном старте оболочки. Проверить очень просто. Пишем в ~/.bash_profile строку echo 'bash_profile', а в ~/.bashrc echo 'bashrc'. Теперь логинимся и запускаем еще одну копить оболочки (т.е. запуск bash без login-а):
bash_profile
[user@server ~]$ bash
bashrc
[user@server ~]$ exit
[user@server ~]$


Зависит от задачи, стоящей перед юнит тестированием.
Если задача оценить «случайность» алгоритма и если не требуется автоматизировать этот процесс, то может помочь следующее:
На плоскость выводится точка, координаты которой берутся из двух вызовов функции генерации случайного числа. То есть:
X=rand
Y=rand
DrawPoint( X, Y )
Если в результате будут какие либо закономерности в распределении точек, то «случайность» алгоритма «хромает»
PS:
Помнится в прошлом веке, такой тест функции RND из BASIC приводил к рисованию практически прямой линии, с небольшими выбросами.

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

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

Если у нас выйдет нормальное распределение случайной величины — поидее это гуд. Но я так же давно теорвер не вспоминал… так что полной уверенности нету.

Не открывается сайт?! — Обязательно спроси на хабре!

man lilypond

Тут настройки: File -> Settings -> Project Settings -> Code Style -> Spaces
Применить форматирование: Code -> Reformat Code (Ctrl+Alt+L)

— Количество записей считаем с помощью for… in
— Сделайте records глобальной и она будет видна везде.

Изучите БЭМ.

Можно реализовать это с помощью jQuery.offset() и jQuery.scrollTop(). Ну и выбрасывать, например, trigger(«shown»)

Не надо возносить маки на уровень выше неба. Железо у них стоит то же самое, что и на остальных ПК.
То есть действовать надо как обычно: ставится винда, смотрятся ID-шники оборудования и ищутся дрова по просторам инета. Хотя, почти уверен, что есть блоги или даже сайты, посвященные «лечению» маков от макОсей. Автору, по ходу, просто лень открыть поисковик любой.

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

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

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

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

Минусы(проблемы) обоих подходов:
— Контролировать работу/качество разработчиков можно только при помощи код ревью и никакие сидения за компом по 8 часов в день в офисе или закомиченые строчки кода с удаленки не дадут 100% гарантии.
— При любом подходе необходимы сервера авторизации CVS, билд стенды и тестовые стенды с копиями(или аналогами) боевых баз(БД).

P.S.
Это конечно далеко не полный список, но я постарался выписать основное.