Рубрика «отладка» - 28

Писать многопоточные приложения нелегко. Некоторые средства статического анализа кода позволяют помочь разработчикам, давая возможность чётко определить политики поведения потоков и обеспечить автоматическую проверку выполнения этих политик. Благодаря этому появляется возможность отлавливать состояния гонки потоков или их взаимной блокировки. Эта статья описывает инструмент анализа потокобезопасности С++ кода, встроенный в компилятор Clang. Его можно включить с помощью опции командной строки −Wthread−safety. Данный подход широко распространён в компании Google — полученные от его применения преимущества привели к повсеместному добровольному использованию данной технологии различными командами. Вопреки популярному мнению, необходимость в дополнительных аннотациях кода не стала бременем, а наоборот, дала свои плоды выражающиеся в упрощении поддержки и развития кода.

Предисловие

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

Средства статического анализа кода помогают разработчикам определить политики потокобезопасности и проверять их при сборке проекта. Примером таких политик могут быть утверждения «мьютекс mu всегда должен использоваться при доступе к переменной accountBalance» или «метод draw() должен вызываться только из GUI-потока». Формальное определение политик даёт два основных преимущества:

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

Данная статья рассказывает о применении данного подхода в Clang, хотя изначально он был разработан для GCC, однако версия для GCC более не поддерживается. В Clang данная возможность реализована как предупреждение компилятора. В Google на данный момент вся кодовая база C++ компилируется с включенным по умолчанию анализом потокобезопасности.
Читать полностью »

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.Читать полностью »

image
Маргарет Гамильтон стоит рядом с написанным ей исходным кода бортового компьютера «Аполлона»

Лаборатория реактивного движения (Jet Propulsion Laboratory) — научно-исследовательский центр НАСА, ответственный за большинство беспилотных космических кораблей США. Там пишут много кода, и права на ошибку у них намного меньше, чем у обычных программистов.

В JPL пишут на Си, и на их сайте есть документ "JPL Institutional Coding Standard", описывающий жесткие стандарты кодирования внутри организации. Они напоминают правила программирования для встроенных (embedded) систем и систем реального времени, с ограниченными ресурсами. Но многие из правил эти просто принципы хорошего программирования. Ограничение сложности, максимальное упрощение для последующего чтения кода и отладки, отсутствие побочных эффектов. Мы в Хекслете постоянно говорим об этом в вебинарах и, конечно, в самих курсах. Мы считаем очень важным как можно раньше поднимать эти темы, поэтому про функции и побочные эффекты начинаем говорить в самом первом курсе «Основы программирования», который рассчитан на новичков. Это бесплатный курс, кстати, и в нем есть практика на языке JavaScript.

В документе JPL есть много правил, но пользователь Реддита сделал выжимку десяти главных принципов. Вот перевод этого списка.Читать полностью »

Привет!
На самом деле пост об одной строчке в документации, как оказалось. Но это было неожиданно, поэтому я решил поделиться с Вами найденным.
Читать полностью »

Всем привет! Сегодня я хочу рассказать об одном своем проекте, который создавался как один из инструментов получения данных для диссертации, и так как на данный момент он свою основную задачу выполнил, я хочу пустить его в GPLv3-плавание — быть может, он будет полезен кому-то еще. Однако перед тем, как отдать швартовы, я решил воспользоваться профилировщиком Intel Vtune Implifier, чтобы убедиться в том, что мой пакет имитационного моделирования древовидной сети электроснабжения оптимально расходует вычислительные ресурсы компьютера.

Node-SPICE: Моделирование переходных процессов в электрической сети - 1

Под катом подробности про себя, про проект и про оптимизацию производительности (которую за полчаса удалось повысить более, чем в два раза)
Читать полностью »

image

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

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

Перевод Анастасии Грызуновой, Яны Щекотовой. Приведение текста в порядок — CaptainCrocus. Помощь в публикации — компания Edison.

Оригинал — Hackers and Painters (May 2003)

Пол Грэм: Глава 2. Хакеры и художники (Habr edition) - 2
Закончив аспирантуру по computer science, я пошел на художественный факультет изучать живопись. Многие удивились, что компьютерщик вдруг заинтересовался живописью. Эти люди, видимо, считали, что хакерство и художество — очень разные занятия: хакерство — холодное, точное и методичное, а художество — яростное выражение некого первобытного порыва.

Оба представления неверны. У хакерства и художества масса общего. Из множества различных типов людей хакеры и художники — едва ли не самые похожие.

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

Мне никогда не нравился термин «computer science». Главным образом потому, что такой науки не бывает. «Computer science» — мешок старьевщика, куда история капризно свалила кучу слабо связанных областей науки — получилась какая-то Югославия. На одном полюсе математики, которые зовут свою работу computer science, чтобы получать гранты DARPA. На экваторе — какое-нибудь компьютерным естествознание: скажем, поведение алгоритмов при передаче данных по сетям. А на другом полюсе — хакеры; они пишут интересное ПО, и компьютеры для них — только среда самовыражения, как бетон для архитектора или краска для художника. Все равно что математиков, физиков и архитекторов согнать на один факультет.

Иногда работу хакеров называют «программной инженерией» (software engineering). Этот термин тоже сбивает с толку. С тем же успехом можно назвать инженером архитектора. Между архитектурой и инженерией граница нечеткая, однако она есть. Проходит она между «что» и «как»: архитектор решает, что делать, инженер вычисляет, каким образом.Читать полностью »

«Инвесторы и аналитики спрашивали нас о том, что мы запланировали на будущее. Нашим настоящим ответом было бы: «У нас вообще нет планов».»
— Пол Грэм, разработчик, инвестор, эссеист.

Мне было любопытно познакомиться с прогнозом основателя самого влиятельного бизнес-инкубатора кремниевой долины (Y combinator). Спустя 15 лет с момента публикации эссе Пола Грэма, благодаря компании Edison и отличным людям с Хабра, руки дошли до перевода. Для тех, кому интересно, как происходило зарождение нового продукта и как три программиста бодались с гигантами индустрии, добро пожаловать под кат.

Пол Грэм, «Хакеры и художники», глава 5: «The Other Road Ahead», продолжение - 1

Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод спасибо Щекотовой Яне)

Читать первую часть главы.

Подход к делу

Иметь возможность выпускать программу незамедлительно — существенный мотиватор. Часто по пути на работу я думал об изменениях, которые мне хотелось внести в приложение, и вносил их в тот же день. Это также работало и для более крупных фич. Даже если на написание чего-то требовалось две недели (а на некоторых проектах и того больше), я знал, что смогу увидеть результат как только все будет реализовано.

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

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

Intro

В этом году Google впервые организовал соревнования по захвату флага — Google Capture The Flag 2016. Соревнования длились двое суток, за время которых нужно было выжать из предлагаемых тасков как можно больше флагов. Формат соревнования — task-based / jeopardy.

Как заявил гугл, задания для этого CTF составляли люди, являющиеся сотрудниками команды безопасности гугла. Поэтому интерес к данным таскам, как и к первому GCTF в целом, был достаточно велик — всего зарегистрировалось ~2500 команд, из которых только 900 набрали хотя бы 5 очков на решении тасков (опустим ботов и немногочисленные попытки играть нечестно). Принять участие можно было любому желающему, начиная от rookie и любителей безопасности и заканчивая легендами отраслей. Кроме того, можно было участвовать и в одиночку.

Так как я специализируюсь в основном на безопасности мобильных приложений, то большую часть от 2х суток я ковырял задания категории Mobile. И в этом хабе будут представлены writeup`ы всех тасков из этой категории. Гугл предложил всего 3 задания для этой категории(в других было по 5-6), но от этого они были, возможно, даже более качественными.

Ну ладно, вода закончилась, переходим к сути :)

Читать полностью »

«Для Viaweb мы часто делали три-пять версий в день.»
— Пол Грэм, разработчик, инвестор, эссеист.

Мне было любопытно познакомиться с прогнозом основателя самого влиятельного бизнес-инкубатора кремниевой долины (Y combinator). Спустя 15 лет с момента публикации эссе Пола Грэма, благодаря компании Edison и отличным людям с Хабра, руки дошли до перевода. Для тех, кому интересно, как происходило зарождение нового продукта и как три программиста бодались с гигантами индустрии, добро пожаловать под кат.

image
Пол Грэм, Роберт Моррис и Тревор Блэквел в 1995

Очередная глава книги «Хакеры и художники» (которая уже почти полностью переведена на русский)

Другая дорога в будущее

Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод плюсик в карму knagaev)

(Эта статья объясняет почему многое в ПО следующего поколения может быть реализовано на серверной стороне, что это будет значить для программистов, и почему этот новый вид ПО будет хорошей возможностью для стартапов. Источниками статьи были диалоги в BBN Labs.)

Летом 1995-го я со своим другом Робертом Моррисом (Robert Morris) решили запустить стартап. PR-кампания перед IPO Netscape тогда шла полным ходом, и в прессе было полно разговоров об электронной коммерции. На тот момент в сети уже было порядка тридцати реальных электронных магазинов, и все они были сделаны вручную. Если в скором времени в сети должно было появиться множество онлайн-магазинов, была потребность в ПО для их разработки, и мы решили такое написать.

Сначала, где-то около недели мы думали, что это будет обычное приложение для ПК. Но потом у нас возникла идея разработать приложение, которое будет исполняться на нашем веб-сервере, с использованием браузера в роли пользовательского интерфейса. Мы попробовали переписать приложение для работы в Вебе, и стало понятно, что это правильное направление. Если мы писали наше ПО для исполнения на сервере, это было удобнее как для пользователей, так и для нас.

Оказалось, что это был отличный план. Теперь, как Yahoo Store, это ПО является самым популярным конструктором онлайн-магазинов, с ним работает порядка 14 тысяч пользователей.
Читать полностью »

Сегодня мы выпускаем первую, экспериментальную и ознакомительную версию отладчика для набора инструментов ASP.NET Core CLI в составе редактора Visual Studio Code. Вначале я должен упомянуть несколько вещей:

Этот первый выпуск поддерживает точки останова, пошаговое выполнение, отслеживание переменных и стеки вызовов.

Экспериментальная функция отладки .NET Core в Visual Studio Code - 1

Однако, .NET Core и функции отладки находятся на ранних этапах разработки, поэтому в VS Code отсутствует ряд возможностей, привычных для пользователей IDE Visual Studio. Вот некоторые особенности редактора:
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js