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

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

Все остальные правила для меня выглядят совершенно, ну просто абсолютно произвольно. Почему у нас есть 12 нот, но для их обозначения применяются только 7 букв? Откуда взялись знаки при ключе? Почему ни одну статью по музыке в Википедии просто невозможно понять, не прочитав сперва все остальные?

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

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

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

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

1. Интро. Личное

Я готовлюсь к языковому экзамену IELTS (International English Language Testing System) — пожалуй, самому популярному
тесту на знание английского. Если хочется эмигрировать, найти работу в международной компании — диплом IELTS очень пригодится. Шкала оценок — от 0 (от испытуемого не удалось получить даже внятного мычания) до 9 (экcперт — испытуемый чертовски хорош и может устроиться даже редактором лондонской газеты).

Для учебы, например, в США, нужно не менее 6.5 баллов (бывает и 6, но не часто), для работы — 7 и выше. А для эмиграции, допустим, в Канаду — чем выше оценка, тем лучше. Мой прогнозируемый балл перед сдачей теста — 5.5. Значит, что я могу читать газеты, смотреть кино, вести беседы в знакомых ситуациях, писать ответы на письма. Но для работы в центральном офисе Гугла явно недостаточно.

Что же делать, чтобы подтянуть уровень языка? Конечно же, начать использовать его в своей жизни как можно чаще и больше. Например, читать книги на английском.

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


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

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

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

Прошлой осенью прошла менеджерская конференция LeanKanban Russia-2014.

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

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



Конференция чисто менеджерская, от поднимаемых тем и аргументов, и местами сильно избитого бизнес-жаргона, у «сферического линейного разработчика» наверняка будет butthur идиосинкразия («WAT?? Процессы? Инновации? Менеджеры-бездельники! Фигли думать, трясти надо!»), но с точки зрения менеджмента — это самые свежие тренды. Так что наверно, в отделенном от хабра мозге мегамозге, обзору будет самое место.

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

В один прекрасный день у тебя в доме начинается капитальный ремонт систем водоснабжения и водоотведения. Рабочие снимают старые стояки подачи воды и канализации, и на несколько дней ты становишься чуть-чуть космонавтом — обтирание влажными салфетками вместо душа, ёмкости питьевой, технической и отработанной технической воды, ассенизационная ёмкость с хлоркой от запаха и прочие неудобства. К счастью, более чем полувековая история космических полётов хранит достаточно историй для отвлечения и поднятия настроения. В самом деле, любой ремонт меркнет перед неудобствами, выпавшими на долю, например, Фрэнка Бормана и Джима Лоувелла на «Джемини-VII».

В данной статье я бы хотел поделиться опытом использования разных методик управления разработкой (Waterfall, Scrum, Kanban) в компании Acronis и рассказать, чем был обусловлен выбор той или иной методики или практики.

Для начала пара вводных слов. Цикл разработки продукта у нас в Acronis, как правило, длится от полугода до года. В разработке принимает участие команда из 40-45 человек. Сам продукт является системным приложением, а основная разработка идет на C++. Важный момент: продукт должен быть выпущен точно в срок не позднее фиксированного момента времени (да-да, и такое бывает).

Последнее детище нашей компании – ATI, в миру известный как Acronis True Image. Этот продукт довольно давно в разработке – настолько, что мы успели написать о нем на Хабр не одну, не две и даже не три статьи (четвертую найдите сами). Команда разработчиков ATI достаточно внушительная, а потому у нас накопился большой опыт управления подобными проектами.

Итак, когда-то очень давно у нас была классическая «водопадная» модель разработки:
Требования -> Дизайн -> Реализация -> Тестирование и стабилизация -> Поддержка.

Всю рутину, которую можно отдать роботам, нужно отдать роботам. Большие системы без этого невозможны. В разработке и тестировании очень много похожих задач, которые не требуют высокой квалификации, но отнимают много времени. Человек, который умеет обеспечить разработку, тестирование и деплой – это редкий специалист и его на количество страничек никак не масштабируешь.

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



Курс открывает моя лекция о том, зачем вообще автоматизировать процесс разработки. Из нее вы получите представление о то, что будут рассказывать мои коллеги.

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

Привет всем!

В предыдущем посте было рассказано о трудностях, которые испытывают разработчики при написании SQL-кода (причём актуальны эти проблемы не только для MS SQL Server). Здесь же рассказ о том, как использовать Git для версионного контроля кода SQL Server с помощью SQLFuse. Принцип тот же, что и с обычными файлами, но есть некоторые особенности.