Введение

После продолжительного перерыва мне пришлось вернуться к программированию на C++. После C# очень не хватало ключевого слова var и возможностей построения запросов linq. Однако как оказалось прогресс не стоит на месте и за время моего отсутствия вышла новая версия С++11, имеющая новые интересные возможности, к тому же реализованная в большинстве компиляторов. Я занимался кросс-платформенным проектом и меня интересовали компиляторы GCC для Linux, Visual Studio и mingw для мира Windows. Попытка найти linq-like библиотеку не увенчались успехом, все, что я находил, было нежизнеспособной поделкой на коленке. Смирившись, я бросил поиски, однако в апреле 2012 вышла обнадеживающая статья LINQ to Objects на языке C++, в которой описывалась библиотека, которая мне подходила. Попробовав ее в деле и разобравшись в ее устройстве, я был разочарован неэффективностью, но некоторые идеи я подчерпнул. Оставалось одно – написать такую же, только с блэк-джеком, что я и сделал github.com/drbasic/CppLinq, заодно разобравшись автоматическим выводом типа (auto) и лямбда выражениями.

Проектировалась библиотека так, что бы с помощью fluent-синтаксиса и лямбда выражений пользователь мог построить граф преобразований. Эти графы можно копировать, достраивать, объединять, т.е. реализовать поведение максимально близкое к прообразу Linq to Objects из мира C#. Функционал библиотеки, недолго думая, я позаимствовал из C#, добавив, явный left join и full join. Важным ограничением библиотеки является перемещение по графу преобразования не копий, а указателей на элементы исходной последовательности. Это позволяет эффективно обходиться со сложными элементами коллекций, ведь теперь не происходит накладных расходов на копирование, но исходная последовательность из-за этого не должна быть «виртуальной». Т.е. к началу работы у каждого элемента исходной последовательности должен быть уникальный адрес и элементы не должны перемещаться в памяти во время работы linq-преобразований. В общем, для этого подходят массивы, контейнеры Qt, все стандартные контейнеры, кроме std::bitset. Сложности возникли лишь с константными последовательностями, которые так и не доделал, так как мне они были не особо нужны. Библиотека проверена и успешно компилируется Visual Studio 2010 и 2012, gcc 4.8, mingw 4.8. Проще всего совладать оказалось с компилятором Microsoft, сделать счастливыми gcc было куда сложнее, причем с внутренней ошибкой бывало падали все компиляторы, порой даже без вразумительных криков.

Компьютер DEC с носителем DECtape

На Github выложили last1120c и prestruct-c — ранние версии самого первого компилятора С в истории. Код написан самим Деннисом Ритчи в 1972-1973 гг.

Компиляторы найдены несколько лет назад на старой магнитной ленте DECtape, вставленной в антикварный компьютер VAX производства компании DEC.

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

А что если отказаться от рамок времени? Что изменится? Вам хватает 24 часа в сутках? Когда эта мысль пришла мне в голову, и я не мог не проверить её на себе. Под катом моя история и ощущения двух недель жизни без часов и без времени. Если кратко: оно того стоит!

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



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

Случалось ли в твоей жизни, %username%, такое, когда тебе продолжительное время хотелось странного? Неважно чего — ведь у каждого разные вкусы и предпочтения. Моя страсть сидела во мне долго, но однажды всё-таки вырвалась наружу. Мне нравится делать необычные вещи, и мне всегда нравился моддинг как средство самовыражения. Несколько лет назад я вдохновился изделиями моддеров из разных стран и начал обдумывать несколько своих проектов. В частности, мне очень хотелось сделать стилизованную под девятнадцатый век клавиатуру.

Потрясающая работа, проделанная умельцем.



Пока автор делал этот шедевр, он:
— получил кучу знаний по оптике и лазерам
— научился работать с ПЛИС (оно же FPGA)
— использовать USB2.0 на полной скорости (поток точек и тайминги идут по usb в плис)
— познакомился с Qt
— научился писать драйвера под Linux

Впечатляет.

_{Не в совокупности ищи единства, но более – в единообразии разделения.
Козьма Прутков}

Немного воды вначале

Нельзя не заметить, что аспектно-ориентированное программирование с каждым годом берет новые рубежи популярности. На хабре было уже несколько статей посвященных этому вопросу, от Java до PHP. Пришло время обратить свой взор на С/C++. Теперь я в первом же абзаце признаюсь, что речь пойдет не об «настоящих аспектах», но о чем-то, близко с ними связанном. Также рассуждение будет вестись в контексте embedded-проектов, хотя описываемые методы могут применяться где угодно, но именно embedded, это та область, где эффект будет максимально ощутимым. Еще я буду использовать слова «хидер» и «дефайн» для обозначения, соответственно, «заголовочного файла» и «макроопределения». Сухой и академичный язык это хорошо, но в данном случае, мне кажется, все будет проще понять, если пользоваться устоявшимися англицизмами.

Если ты всегда мечтал написать свой язык программирования — добро пожаловать. Здесь ты наверняка найдёшь для себя что-нибудь интересное.

GitHub-юзер yawnt собрал чудесную подборку ссылок для любителей драконов, языков и прочих вкусных внутренностей. А знающие камрады в комментариях наверняка поделятся с тобой и другими яствами.

Пишет yawnt следующее:

С каждым днём мне всё интереснее тема компиляторов, интерпретаторов и дизайна языков программирования в целом. И я решил поделиться с народом ссылками на собранные мной материалы (большую часть мне самому ещё предстоит прочитать :<). Надеюсь, кому-нибудь они окажутся полезными.

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

В этой короткой заметке я хотел бы систематизировать (а именно, расположить в иерархию) многие популярные принципы проектирования программных приложений (test-driven development, ООП, SOLID и т. д.), а также рассмотреть следствия из этой иерархии.

В частности, такая иерархия (я надеюсь) позволит лучше расставлять приоритеты в разработке и профессиональном росте, лучше понимать старые технологии и быстрее изучать новые. При появлении новой парадигмы разработки (a la test-driven development) вы сможете быстро включить ее в эту иерархию и, следовательно, быстрее понять, из каких принципов исходили создатели парадигмы и как правильно ее использовать. Новичкам в программировании статья может быть полезна как обзор существующих принципов.

И в качестве самого базового я полагаю разумным считать принцип «управления сложностью/минимизации технической сложности» МакКоннела. А самыми важными срествами минимизации сложности являются модульность и абстракция.

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

DISCLAIMER: более навороченной книги по ООП в природе нет и в ближайшее время, скорее всего, не будет; эта книга заслуженно считается классической книгой по объектной технологии и не зря является первой в списке рекомендуемых книг по этой теме (причем она первая не только в моем списке).

Основная сложность при изучении объектно-ориентированного программирования (или любой другой парадигмы программирования) заключается в том, что весьма сложно подобрать формальные критерии, которые бы сказали: «ок, теперь я знаю ООП и стану писать более клевые (читай модульные, реюзабельные и легкие в сопровождении) программы». Например, при изучении языков программирования мы относительно быстро замечаем, опа, level-up, я, кажись, перешел на новый уровень понимания идиом и конструкций языка программирования и могу использовать его более интересным образом, да еще и другим рассказывать, где они не правы.

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

Продолжение перевода здесь

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

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

В этой статье — продолжаем ковырять микросхемы (а если вы пропустили первую статью — она тут).

Под катом — внутренности К565РУ5, Z80, КР580ВМ80А, MSP430F122, PIC16C505, PIC12C508, российского радиационно-стойкого микроконтроллера 1886ВЕ10, STM32F103VGT6, таймер 556, новый чип RFID из билетов Метро и Мультиклет.

Ну и пара слов о более каноническом способе вскрытия микросхем, который оставляет их в работоспособном состоянии.

Финский инженер Оона Ряйсянен (Oona Räisänen) составила чёткую блок-схему с описанием всех звуков, которые издаёт диалап-модем при установке соединения. Горизонтальной оси соответствует время в секундах, вертикальной — частота звука в герцах.

Описание наложено непосредственно на спектрограмму. Для каждого звука помечен источник (наш модем или чужой) и объяснение, что значит конкретно этот сигнал.

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

Каждый — гениален. Но если вы будете судить рыбу по ее способности лазать по деревьям,
она всю жизнь проживет с верой в свою глупость.

Альберт Эйнштейн

Лень — это привычка отдыхать до того, как ты устанешь.

Жюль Ренар

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

Решительно сократить количество проблем можно, придерживаясь следующих рекомендаций:

1. В голове держать не больше трех-пяти вещей за раз, объединив действия в большие смысловые блоки.
2. Раз и навсегда выбрать решение по ежедневному набору мелочей: вносить дела к календарь, проверять утюг и т.п.
3. Разложить все вещи по своим местам и поддерживать заведенный порядок.
4. Дублировать необходимые и часто используемые вещи; разложить их по всем углам.
5. Умело пользоваться календарем, мобильником и другими инструментами интернет-века.
6. И самое главное: НЕ ОТВЛЕКАТЬСЯ ПО МЕЛОЧАМ!

Каждый год 31 декабря David Eppstein публикует обзор препринтов за прошедший год, посвященных структурам данных и алгоритмам, опубликованным на arxiv.org. По ссылкам можно познакомиться с материалами за 2010 и 2011 (мой перевод) годы.

Раздел cs.DS развивается хорошими темпами: в этом году появилось 935 препринтов по алгоритмам и структурам данных, в то время как за 2011 их было 798. Раздел пока не дотягивает до сотни в месяц, хотя в июле (98 препринтов) этот порог был очень близок.

Это мой личный список из десятка препринтов, которые кажутся мне особенно интересными. Как обычно, я не вношу в него мои собственные работы и некоторые другие, о которых я писал раньше. Кроме того, здесь нет результатов (например, более быстрый алгоритм нахождения максимального потока), не появлявшихся на arxiv.org.

Вот они, в хронологическом порядке:

Вместо предисловия

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

Перед тем как начать я хотел бы сделать акцент на двух положениях:
Первое. Мы исходим из того что читатель знаком с такими пакетами как 3D Studio MAX (либо любым другим пакетом трехмерного моделирования) и Photoshop (или любым его аналогом). В данном конкретном случае я собираюсь использовать терминологию этих двух пакетов. Однако, не смотря на это те же самые принципы можно использовать, пользуясь любым другим софтом.

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

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

Хочу также отметить, что я не причисляю себя к мастерам, которые делают шедевры. Данное примечание я делаю для тех злых людей, которые говорят (или скажут после публикации), что я заносчив, что меня занесло под небеса, и тех кто вместо того чтобы работать предпочитает злословить словно ябедник Кийр из моей любимой книги Оскара Лутса «Весна».

С преамбулами покончено перейдем к сути.

Я утверждаю и не беспочвенно, что хороший фон можно и нужно создавать не за неделю, не за пять дней и даже не за три. Чтобы сделать хорошую картинку для казуальной игры, без разницы i-spy это, match-3 или аркада, достаточно 48 часов. Разумеется, при условии того, что человек занимается работой, а не просиживанием штанов.

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