См. две другие статьи этой группы — Делаем многозадачность и Преемптивность: как отнять процессор.

Сразу просьба к строгим читателям. Если вы не поняли какой-либо термин из применённых — спросите, я подскажу, что я имел в виду. А если вам нравится другое написание или перевод этого термина — укажите его в комментарии. Я применяю те, которые нравятся мне.

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

Как я уже говорил, шедулер — это просто функция, которая отвечает на вопрос: какую нить и на сколько времени поставить на процессор.

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

Говоря о шедулере нельзя не сказать о приоритетах.

Приоритет — свойство нити (или процесса) влияющее на конкуренцию этой нити с другими нитями за процессор.

Приоритет обычно описывается парой <класс приоритета, значение приоритета внутри класса>.

Представляю вашему вниманию перевод очень ёмкой, и в то же время достаточно краткой (для такого масштаба проблемы) статьи Карла Чео. Я решил, что очень хочу сделать её перевод практически сразу, как только начал читать, и очень рад, что в итоге сделал это.

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

Важные замечания:

• Пункты с неуказанным источником написаны мной самостоятельно. Поправьте меня, если вы заметите какие-то неточности. Предложите лучшую аналогию, если это возможно.
• Заголовки ссылаются на соответствующие им статьи в Wikipedia. Пожалуйста, читайте эти статьи для более серьезных и детальных объяснений.
• Аналогии — отличный способ объяснить материал, но они не идеальны. Если вы хотите по-настоящему понять перечисленные концепции, вам следует начать с фундаментальных азов и рассуждать, исходя из них.

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

Прислали мне как то тестовое задание. Надо написать шахматы на Qt с использованием C++ и QML. QML до этого не изучал, только слышал и читал про него, поэтому решил что напишу только с использованием C++ и библиотеки Qt. Написал, отправил, возвращают и просят графическую часть переписать на QML. Делать нечего, сел за изучения сего чуда и переписал графическую часть. Теперь хочу поделиться приобретённым опытом.

Весь процесс написания шахмат описывать не буду, опишу только процесс постижения QML. Думаю эта статья будет в помощь начинающим в QML.

1. Вступление

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

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

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

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

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

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

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

Фирма АРМ продала более 200 лицензий на ядра Cortex-M, и на рынке представлены тысячи вариантов этих устройств. Хотя фирма создала ядро M7 в прошлом году, которое предлагает невероятную производительность для MCU, начальный уровень линейки ядер продолжает представлять огромный интерес для производителей. Реализация ядра M0 требует около 12000 gates (трудно сказать, идет речь о затворах либо базовых элементах, в любом случае это немного, но в первом — намного меньше — примечание переводчика), так что стоит она чуть больше, чем ничего (реализация, конечно, а не лицензия, кстати, если кто знает цены — поделитесь в комментах — пп). М0 + имеет тот же набор инструкций (как и M0-пп), но показывает лучшую производительность при низком энергопотреблении для устройств с батарейным питанием, плюс расширенные (необязательные) возможности отладки, и даже дополнительный блок защиты памяти (MMU бедняка).

Сегодня хочу рассказать об одном интересном процессе изготовления нестандартного изделия – безэховой волноводной камеры. На первой встрече с заказчиком выяснилось главное требование — сроки. Зарубежные исполнители нестандартных узлов, к которым обратился заказчик, указывали от полугода до восьми месяцев. В процессе общения с заказчиком постепенно вырисовывалась концепция изделия: определили внешний вид, в трех вариантах, в зависимости от технологии изготовления. Было проведено, так сказать, маркетинговое исследование по размещению заказов по деталям и узлам изделия. Сразу определилась основная проблема: заводы и небольшие фирмы, принципиально не отказываясь от единичного изделия, сам процесс затягивали до смешного. То есть, уже на стадии согласования частностей, мы понимали, что и здесь, в России, история потянет на месяцы. Объяснять этот известный факт, думаю, не надо, многие сталкивались. Нам же хотелось сдать готовое изделие уже летом. Поэтому решили, как это ни парадоксально звучит, применить пластики и технологию аддитивного производства.

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

По рабочим эскизам заказчика мы изготовили чертежи и 3D-модель. Размеры в чертежах согласовали по телефону и с помощью электронной почты. Это заняло три дня (чертежи были неполные). Подумали, подумали, да и запустили в печать изделие: посмотреть было очень любопытно, что же за штука будет. Печатали часть на Ultimaker 2 и половину на Пикассо (Российский изготовитель 3D-принтеров).

Я засомневался в своей точке зрения, см. подробнее в одном из UPD.

Хочу поговорить о Wolfram Language (далее WL). Прошу прощения за сумбурность изложения, пост вырос из попытки ответить на этот коммент от Nilis.

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

Лет 6-10 назад, когда я учился в школе, я знал лишь BASIC, Pascal/Delphi, C/C++ и WL. Из ОС имел дело лишь с Windows. Не знал, что такое скриптовые языки (perl, python, bash), не знал самого понятия «скрипт». Думал, что командный интерфейс — это устаревший интерфейс и что единственный правильный интерфейс программы — это графический. Программировал я на Delphi и WL. Программы на Delphi всегда были графическими. За исключением олимпиадного программирования, там в требованиях к программам было, что они должны быть текстовыми, я их писал на Delphi и C++. Когда я узнал о WL, я был им очарован, также как и вы. Потому что код на WL был гораздо короче, чем на Delphi/C++. И вообще, потому что WL был совершенно не похож на Delphi и C++. Потому что там была возможность программировать функционально. Я познакомился с функциональным программированием на примере WL, я не знал, что существуют «стандартные» функциональные языки — Haskell, Lisp и ML.

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

К сожалению, универсальных правил прохождения и проведения собеседования нет и быть не может, потому что сотрудников подбирают не только по их техническим навыкам и личностным качествам, но и по совпадению с некоторым (зачастую неявным и очень субъективным) «профилем», который, по мнению интервьюеров, вписывается в их команду или компанию. Что же касается руководств из серии «как правильно проходить собеседования», то они обычно вызывают не меньше боли в комментариях, потому что очень субъективны и обязательно задевают чьи-нибудь болевые точки.

За свою профессиональную карьеру мне довелось побывать по обе стороны баррикад, хотя, пожалуй, проводить технические собеседования приходилось всё же немного больше, чем проходить их. Но за это время у меня накопилось некоторое количество «пунктиков», которые отпугивают меня во время технического интервью и сразу в моём сознании ставят крест на дальнейшей беседе. Об этом мне и хотелось рассказать — с позиций интервьюера и соискателя. Хочу сразу оговориться, что статья отражает мои личные субъективные впечатления и не претендует на «руководство по прохождению собеседований». С другой стороны, это не минутный всплеск ярости от неудавшегося интервью, а давно взвешенный набор тех критериев, которые, хотя и по негативному принципу, позволяют мне отсеять варианты, либо самому не отпугнуть потенциально подходящего соискателя.

А что на собеседованиях раздражает или напрягает вас? Поделитесь в комментариях.

Подошедший к концу GopherCon 2015, длившийся с 7 по 10 июля в Денвере, отметился немалым количеством интересных выступлений. Видео докладов еще недоступно, однако, конспекты некоторых из них доступны на английском языке по этому адресу; в официальном блоге также можно прочитать программную речь Расса Кокса. Вниманию читателей предлагается конспект доклада об истории создания языка, который открыл второй день конференции.

Роберт Грисмер (@robertgriesemer) — разработчик в Google, один из авторов языка Go. В прошлом Роберт работал над генерацией кода для высокопроизводительного JavaScript, занимался языком программирования Sawzall и разработкой современной реализации Smalltalk — Strongtalk. По собственному заявлению, он «провел слишком много времени в виртуальных Java-машинах, но так и не понял, как ими пользоваться».

Интерес Роберта к языкам программирования возник при знакомстве с Pascal — до этого момента он в основном писал на BASIC. Будучи аспирантом, он обучался у Никлауса Вирта, создателя Pascal.

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

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

Но если не можете забыть о работе даже за шашлыком, то вам поможет только транс. Транс — это самый эффективный и глубокий отдых. Качественнее отдохнуть просто невозможно :)

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

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

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

Статья будет большая и по смыслу делиться на три части
1 – Спектральные характеристики источников света
2 – Как можно померить спектр с помощью прямых рук и «синей изоленты»
3 – Кратко о воздействии света на человека

С некоторых пор фирма Segger предлагает технологию Real Time Terminal (RTT) для своих JTAG адаптеров J-Link. Суть ее в том, что программа на микроконтроллере может выводить и принимать отладочную информацию из JTAG/SWJ-DP порта, как это обычно делается через UART. И тогда нам больше не нужен реальный отладочный UART. Далее чуть подробнее о возможностях этой технологии.

Хочу показать, как можно писать код и собирать hex-файлы для отечественных микроконтроллеров компании «Миландр» в удобной среде Qt Creator. Обычно для этих средств используются другие среды разработки, но с появлением системы QBS все несколько поменялось.

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

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

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

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

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



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

D3 — мощная JavaScript библиотека для визуализации данных. На мой взгляд — просто рай для web-разработчика, казалось бы недоступный для Qt-программиста. Но гибкость фреймворка Qt позволяет интегрировать web-frontend в толстый клиент с помощью механизма Qt Web Bridge. Такие приложения получили наименование гибридные (Qt Hybrid Apps).

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

На скриншоте ниже изображен виджет Dependency Wheel (Круг Зависимостей), отрисовка которого осуществляется с помощью D3.js а управление данными и отображением — с помощью Qt. При нахождении указателя над соответствующей дугой её взаимосвязи «подсвечиваются», а остальные становятся полупрозначными. Данный виджет можно использовать для визуализации различного рода зависимостей (например библиотек).

В отличии от оригинального JS решения диаграмма динамически изменяет размер под размер виджета, а данные устанавливаются на стороне Qt, а не с помощью загрузки JSON-файла.

Статья больше ориентирована на Qt-программистов, но также может быть интересна и JS программистам.

Прошло пять недель с тех пор как вышла альфа версия Rust 1.0! До того как выйдет следующая предварительная версия Rust, мы хотели бы рассказать о текущем состоянии языка и о том, что мы еще намерены сделать по пути к стабильной версии 1.0.

TL;DR: Rust 1.0 выйдет 15 мая 2015 года

Продолжаем обзор деятельности нашего Хакспейс-клуба.

Мы давно мечтали купить в наш клуб ЧПУ станок. Но решили его сделать сами. С нуля, начиная от железа и кончая программного обеспечение (прошивка контроллера и управляющая программа). И у нас это получилось.

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

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

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

Безопасность

Тактика хакера: практическое руководство по тестированию на проникновение (The Hacker Playbook: Practical Guide To Penetration Testing)

Книга написана в стиле планирования футбольной игры. Здесь подробно и пошагово разобраны проблемы и трудности, с которыми сталкиваются специалисты по безопасности, тестируя системы защиты. В частности, рассматриваются атаки на различные типы сетей, обход антивирусов и взлом систем безопасности. Автор книги — Питер Ким, специалист по IT-безопасности с многолетним опытом, CEO компании Secure Planet.