Предлагаю вам перевод дневника Руи Уэяма (Rui Ueyama), программиста из Google, который он вел во время работы над реализацией компилятора языка C около трех с половиной лет назад (но опубликовал только в минувшем декабре).
Этот дневник не несет какой-то практической пользы и не является туториалом, но мне было очень интересно его прочитать, надеюсь и вам эта история тоже понравится :)

Я написал C компилятор за 40 дней, который назвал 8cc. Это дневник написанный мной в то время. Код и его историю можно посмотреть на GitHub.

Приветствую!



Сегодня речь пойдет о том, как добиться высокого качества монтажа на платах с большим количеством компонентов — до 1500шт (можно и больше при плотном монтаже или при сборке 1-2 плат одновременно — не более). Потребность в таком сложном монтаже обычно возникает при изготовлении первого макета или нескольких образцов, чтобы убедиться в правильности трассировки печатной платы (основных сложных моментов) или же при разовом производстве. После получения такого макета можно начинать отлаживать программное обеспечение и вносить корректировки в плату. Заводская сборка, в этом случае, не совсем подходит из-за ее стоимости, подготовки конструкторской документации, подборки компонентов, сроков, макетирования и многого другого (под катом картинки на 8Мб).

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

Неважно, нужно ли вам сделать фотографии с высоты птичьего полёта, доставить книги или просто полетать для удовольствия, дроны становятся всё более популярны. В то же время, разработчики не прекращают поиски новых способов управления ими. Ниже вы можете посмотреть, как команда разработчиков Leap Motion использовала своё творение для бесконтактного управления дронами.

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


Примерный план (посмотрим по ходу действия) ожидается следующий:

1. Hardware выключателя
2. Тестирование и подготовка
3. Software выключателя
4. «Центр управления»

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

Как развивалось помешательство, я решил описать в статье. Получилось длинно, но может кому-нибудь будет интересно. Думаю, статья ориентирована на тех, кто ещё не практиковался в робототехнике.

Вот что получилось в результате. Видео винтажное, снималось владельцем iPhone, а они ведь затейники, ну вы знаете. Звук я оставил закадровый сознательно, чтоб всё жужжало как взаправду.

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

Преамбула

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

Идея была собрать более или менее компактного робота, но достаточно проходимого и функционального. Я не хотел привязываться к каким-то определённым платформам или собирать китовые наборы, поэтому решил отдельно заказывать детали и стараться по максимуму делать из подручных средств.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы покажутся чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он будет полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Введение

Многие современные программисты, пишущие классные и широко распространённые программы, имеют крайне смутное представление о теоретической информатике. Это не мешает им оставаться прекрасными творческими специалистами, и мы благодарны за то, что они создают.

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

Я надеюсь, что эта статья станет началом цикла заметок о lock-free структурах данных. Я хочу поделиться с хабрасообществом своим опытом, наблюдениям и размышлениями о том, что такое lock-free структуры данных, как их реализовывать, подходят ли концепции контейнеров стандартной библиотеки STL к lock-free контейнерам, и когда стоит (и стоит ли вообще) применять lock-free структуры данных.

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

Одна из проблем нашего высшего образования в том, что в вузах учат много чему, и алгоритмам, и языкам программирования, и ООП, и даже паттернам проектирования. Но я еще ни разу не встречал, чтобы в вузах учили работать работу. Лабораторки не в счет. Спихнул – и забыл! Возможно, просто не везло.

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

Итак, про семь навыков…

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

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

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

В этом блоге мы уже много о чём поговорили: были краткие описания основных рекомендательных алгоритмов (постановка задачи, user-based и item-based, SVD: 1, 2, 3, 4), о нескольких моделях для работы с контентом (наивный Байес, LDA, обзор методов анализа текстов), был цикл статей о холодном старте (постановка задачи, текстмайнинг, теги), была мини-серия о многоруких бандитах (часть 1, часть 2).

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

Одним из самых больших нововведений в PHP 5.5 будет поддержка генераторов и корутин (сопрограмм). Генераторы уже достаточно были освещены в документации и в нескольких других постах (например в этом или в этом). Сопрограммы же получили очень мало внимания. Это гораздо более мощный, но и более сложный для понимания и объяснения, инструмент.

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

Генераторы

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

Приветствую вас, Хабражители!

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

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



Помните 7 шагов?

Всем привет!
Хотел бы поделиться с Вами наиболее полной информацией о тенденциях и направлениях веб-дизайна уже в нынешнем 2013 году.

Многие уже слышали о проекте WebRTC, некоторые даже используют его (или пытаются применять в существующих проектах), а кто-то злобно потирает руки, предвкушая постепенную расправу со Skype и Flash.

Погуглив в Хабре (хе-хе) я почему-то не нашел статей, которые углублялись в техническую сторону WebRTC, показывали бы примеры его использования.

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

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

Итак, я просил ответить на вопрос какие книги из статьи вы читали?

Результаты опроса:

Название книги	Количество голосов	Процент
Том ДеМарко. Deadline. Роман об управлении проектами	247	54%
Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы	174	38%
Джоэл Спольски. Джоэл о программировании	165	36%
Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды	148	32%
Джейсон Фрайд, Дэвид Хайнемайер Хенссон. Rework. Бизнес без предрассудков	108	24%
Джеффри Янг и Уильям Саймон. iКона. Стив Джобс	94	21%
Том ДеМарко, Тимоти Листер. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения	70	15%
Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд	51	11%
Кармин Галло. iПрезентация. Уроки убеждения от лидера Apple Стива Джобса	48	11%
Патрик Ленсиони. Смерть от совещаний	21	5%
Патрик Ленсиони. Пять пороков команды. Притчи о лидерстве	19	4%
Патрик Ленсиони. Пять искушений руководителя: притчи о лидерстве	16	4%
Патрик Ленсиони. Три признака унылой работы. История со смыслом для менеджеров (и их подчиненных)	11	2%

А теперь еще один бонус — список книг по заданной тематике, которые прислали нам читатели:

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

В отечественном IT я часто наблюдаю следующую картину: тимлидом часто становился лучший (?) разработчик из команды (aka 23-летний сеньор). А чтобы стать руководителем проекта (project manager) иногда достаточно просто знать английский и «павэрпойнт» на уровне пользователя. Это реалии отечественного аутсорсинга и с этим нужно как-то жить.

В итоге часто получается как-то так:

Потому что на десять сеньоров по статистике девять тупят.