Все вы знаете систему Git. Хотя бы слышали — это наверняка. Разработчики, которые пользуются системой, ее или любят, или ругают за сложный интерфейс и баги. Система управления версиями Git де-факто является стандартом в индустрии. У разработчика могут быть мнения о преимуществах Mercurial, но чаще всего приходится мириться с требованием уметь пользоваться Git. Как у любой сложной системы, у нее множество полезных и необходимых функций. Однако, до гениальной простоты добираются не все, поэтому существующая реализация оставляла пространство для совершенствования.

Простыми словами — мудреным приложением было трудно пользоваться. Поэтому в лаборатории Массачусетского Технологического Института взялись за улучшения и отсекли все «проблемные элементы» (ведь то, что для одного проблема, для другого легко может быть преимуществом). Улучшенную и упрощенную версию назвали Gitless. Её разрабатывали с учетом 2400 вопросов, связанных с Git и взятых с сайта разработчиков StackOverflow.

Команда авторов вычленила самые проблемные места в Git, включая две концепции staging и stashing. Затем они предложили изменения, призванные решить известные проблемы.

2 года назад я увидел запись «Предел минимального Hello Word на AVR составляет 2 байта» на Habrahabr`е пользователя swap_map с подначиванием в конце:

Кто-нибудь напишет программу мигания светодиодом еще короче?

Тогда я посчитал, что это просто невозможно, но сейчас я смог это сделать.

Не всегда разрабатываемое решение работает с приемлемой производительностью. Особенно для заказчика. И если предложение докупить памяти и поднять системные требования не срабатывает (у меня ни разу не получалось), приходится браться за оптимизацию. И для этого у нас есть не только StopWatch: об инструментах, которые позволяют понять, где искать, куда лезть в первую очередь, каких результатов ждать, работая над перфомансом приложения, поговорили с прекрасной девушкой, отличным специалистом и докладчиком конференции DotNext 2016 Moscow — Диной Гольдштейн.

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

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

Тогда я написал пост «Заблуждения программистов относительно „времени“», в котором указал 34 ошибочных представления и заблуждения, относящихся как к календарному, так и к системному времени. С большинством из них я столкнулся сам, занимаясь дебаггингом программ (как рабочих, так и тестовых).

Есть одна тема в современном Computer Vision, которая часто остаётся за кадром. В ней нет сложной математики и глубокой логики. Но то что её никак не освещают — вгоняет в ступор многих новичков. А тема не проста: имеет множество граблей, про которые не узнаешь, пока не наступишь.

Тема — называется так: подготовка базы изображений для дальнейшего обучения.
В статье:

1. Как можно отличить хорошую базу
2. Примеры хороших баз
3. Примеры программ, которыми удобно размечать базы

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

Сегодня я наконец-то заканчиваю описание программной части — остались вопросы связанные с выводом на TFT-дисплей изображений и кириллицы. Сделаем всё красиво.



Содержание цикла публикаций:

• [Часть 1] Обзор использованных программных и аппаратных решений.
• [Часть 2] Начало работы с графическим контроллером FT800. Использование готовых mbed-библиотек для периферийных устройств.
• [Часть 3] Подключение датчика HYT-271. Создание и публикация в mbed собственной библиотеки для периферийных устройств.
• [Часть 4] Разработка приложения: Структура программы, работа с сенсорным экраном.
• [Часть 5] Разработка приложения: Вывод изображений на дисплей, проблемы русификации.
• [Часть 6] Печать деталей корпуса

Доброго времени суток %HabraUser%! Не так давно мне посчастливилось стать обладателем VDS с предустановленным Windows Server 2016 для ознакомления с данной операционной системой и ее новыми возможностями. В связи с тем, что последние несколько лет я являюсь поклонником администрирования с использованием PowerShell, в первую очередь меня заинтересовал именно он, так как применяю его в своей работе ежедневно для автоматизации рутинных задач. В корпоративной среде на сегодняшний день чаще всего последняя используемая версия операционных систем Windows 8.1 и Windows Server 2012 R2, соответственно я не обращал внимания, на изменения, которые принесла мне Windows 10 на домашнем компьютере, и как оказалось зря. Я пропустил мимо себя обновленный инструмент, который стал гораздо лучше, удобнее и быстрее по сравнению с предыдущими версиями, об этих основных изменениях и хотелось бы поговорить. Добро пожаловать под кат.

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

Не так давно в сети появился пост Immo Landwerth, который рассказывает о .NET Standard 2.0
Если вкратце, то это унификация .NET для следующих веток .NET Framework, .NET Core и Xamarin. Выражаясь понятными словами это набор API, который будет реализован всеми платформами.

И сразу значительное изменение: .NET Standard заменит библиотеки PCL. Хотя для разработчиков суть и останется прежняя, реализация будет другой. Ездить машина будет, как и раньше, но изменится название и содержимое под капотом (пожалуй, в лучшую сторону).

В июне 2016 вышел релиз ASP.Net Core 1.0 и теперь, если вас не пугает возраст нового фреймворка, можно аккуратно запустить микросервис в продакшн (все ведь используют микросервисную архитектуру, не так ли?). Для того, чтобы ограничить доступ к вашему микросервису для третьих лиц, необходимо сделать аутентификацию, используя довольно распространенный способ — токены. В статье под катом мы расскажем подробнее о том, как это сделать с помощью JSON Web Token (JWT), а также о плюсах и минусах этого подхода.

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



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

В преддверии нашей встречи, которая будет посвящена инфраструктуре Яндекса, мы решили рассказать о YQL читателям Хабрахабра.

В этой статье мы поговорим о шаблонах проектирования «Единица работы» и «Репозиторий» в контексте тестового веб-приложения на ASP.NET Core (с использованием встроенного DI), которое мы с вами вместе и разработаем. В результате мы получим две реализации взаимодействия с хранилищем: настоящую, на основе базы данных SQLite, и фейковую, для быстрого тестирования, на основе перечисления в памяти. Переключение между этими двумя реализациями будет выполняться изменением одной строчки кода.

Некоторое время назад я рассказывал о своем боте для Telegram, который умеет данные из Google Analytics показывать. А тут Microsoft объявила о запуске ботов в Skype — самое время изучить как это работает. Под катом — небольшое описание возможных проблем. Кому не терпится посмотреть результат, вот он — MetricsBot .

Дано: система с 10-летней историей, разработанная на C#, с довольно большой кодовой базой. Серверной частью системы является веб-сервис (хостится в IIS, протокол SOAP), активно работающий с базой данных, с кэшированием в Redis, с различными проверками безопасности, поиск в Elasticsearch.

Задача: обеспечить работу системы на Linux без потери в производительности с минимальными телодвижениями.

Все мы ходили по собеседованиям, разговаривали с представителями компаний и постоянно встречаемся с особенностями, которые рекрутеры либо культивируют, обучая друг друга, либо не обращают внимания, но при этом выглядят отталкивающими — со стороны человека, пришедшего в компанию. В моей 10-летней карьере я сменил порядка 10 компаний (в последней — Luxoft — уже 3 года, так что практику перебежчика закончил). И за это время провел как около 100 собеседований на стороне соискателя, так и порядка 150 — на стороне собеседующего, что дало мне возможность собрать Топ5 ошибок рекрутеров, которые могут так испортить собеседование, что я больше не захочу идти в компанию.

Эта статья — ревью на книгу «Growing Object-Oriented Software, Guided by Tests» (GOOS для краткости). В ней я покажу, как можно имплементировать проект-пример из книги без использования моков (mocks).

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

Версия на английском: ссылка.

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

Продолжаем делиться материалом по работе с ASP.NET Core. В прошлой статье мы рассказывали о развертывании приложения ASP.NET Core на Nano Server со службами IIS. Сегодня поговорим о создании внешнего интерфейса веб-службы для вашего приложения.

Сразу две популярные новости на этой неделе поднимают важную тему оценки серьезности уязвимостей в частности и определения безопасности софта или железа вообще. По порядку: 3 октября основатель сервиса SSLMate Эндрю Айер сообщил об уязвимости в демоне инициализации systemd (новость, оригинальный пост Айера). Уязвимость типа denial of service эксплуатируется только локально. Любой пользователь введя команду NOTIFY_SOCKET=/run/systemd/notify systemd-notify “” может подвесить систему. Баг, вызванный неправильной обработкой сообщения нулевой длины, и уже закрытый, просуществовал в systemd два года, начиная с версии 209.

Имея массу примеров для сравнения (Shellshock, например, или тот же Heartbleed), можно вполне уверенно утверждать, что это далеко не самый ужасный в мире баг. Тем не менее, срач обсуждение проблемы получилось масштабное. Причина в доступном описании бага: «можно подвесить систему сообщением, которое помещается в один твит». И в резкой реакции CTO компании Pantheon, активно поддерживающего systemd. Далее везде, вплоть до нового витка обсуждения личности создателя systemd (не буду его называть, а то и здесь начнется).

В общем, обсуждали все, что угодно, только не сам баг, который, действительно, не так уж ужасен, хотя и серьезен. Это действительно важная тема: по уязвимостям пытаются судить о качестве продукта. Типичный пример такого подхода — рейтинги софта с наибольшим количеством обнаруженных дыр. Попробую предложить свою трактовку: уязвимость — это в большинстве случаев просто уязвимость, и само по себе обнаружение проблемы никак не квалифицирует софт или железку. А чтобы обосновать это утверждение, нам понадобится обсудить роутер D-Link.