Эта заметка была написана в 2014-м году, но я как раз попал под репрессии на хабре и она не увидела свет. За время бана я про неё забыл, а сейчас нашёл в черновиках. Думал было удалить, но авось кому пригодится.



В общем, небольшое пятничное админское чтиво на тему поиска «включенного» LD_PRELOAD.

Пару лет назад Kubernetes уже обсуждался в официальном блоге GitHub. С тех пор он стал стандартной технологией для развёртывания сервисов. Теперь Kubernetes управляет значительной частью внутренних и публичных служб. Поскольку наши кластеры выросли, а требования к производительности стали более жёсткими, мы стали замечать, что в некоторых службах на Kubernetes спорадически появляются задержки, которые нельзя объяснить нагрузкой самого приложения.

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

Эта неделя была короткой, в понедельник и вторник я продолжал работать над системой 2D-освещения. Остальное время я потратил на реализацию деревьев квадрантов (quadtree).

В этой статье я поделюсь своей реализацией и мыслями, возникшими в процессе её проектирования.

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

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

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

Привет, Хабр! представляю вашему вниманию перевод статьи «Creating a REST API: Web Server Basics».

Часть 1. Создание REST API: основы веб-сервера

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

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

cd ~
mkdir hr_app
cd hr_app/
touch index.js
mkdir config
touch config/web-server.js
mkdir controllers
mkdir db_apis
mkdir services
touch services/web-server.js

Файл index.js можно рассматривать как «основной» файл в приложении. Он будет точкой входа в приложение. Мы будем добавлять код в этот файл и файлы web-server.js в каталогах config и services.

Вставьте следующий код в файл Home > hr_app > config>web-server.js

module.exports = {
  port: process.env.HTTP_PORT || 3000
};

В Node.js объект процесса имеет свойство env, которое содержит пользовательскую среду. Я использую это, чтобы установить значение порта в значение переменной среды HTTP_PORT. Если эта переменная среды не определена, значением по умолчанию будет 3000.

Казалось бы, какой пост может быть о CSS Flexbox в 2019 году? Верстальщики уже несколько лет активно используют данную технологию, и все тайны должны быть разгаданы.

Однако, недавно у меня возникло стойкое ощущение, что нужно поделиться одним нетривиальным и, на мой взгляд, полезным приёмом, связанным с flexbox. Написать пост побудил тот факт, что ни один знакомый (из учеников, верстальщиков и просто людей, близких к web), не смог решить задачку, связанную с flexbox, хотя на это нужно всего 4-6 строк.

1 часть. Заземление
(общая информация, термины и определения)

2 часть. Традиционные способы строительства заземляющих устройств
(описание, расчёт, монтаж)

3 часть. Современные способы строительства заземляющих устройств
(описание, расчёт, монтаж)

2 часть. Традиционные способы строительства заземляющих устройств (описание, расчёт, монтаж)

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

Г. Основные способы строительства

Г1. Несколько коротких электродов (“уголок и кувалда”)

Г1.1. Особенности решения

Г1.1.1. Промерзание грунта зимой
Г1.1.2. Взаимное “экранирование”/ “затенение” электродов

Г1.2. Расчёт получаемого сопротивления заземления и необходимого количества заземляющих электродов
Г1.3. Монтаж
Г1.4. Достоинства и недостатки
Г1.5. Уменьшение количества электродов

Г2. Одиночный глубинный электрод (“обсадная труба”)

Г2.1. Особенность решения
Г2.2. Расчёт получаемого сопротивления заземления
Г2.3. Монтаж
Г2.4. Достоинства и недостатки

Г. Основные способы строительства

Напомню, в прошлой части я остановился на общем подходе…

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

Интерес к этой области появился у меня спонтанно. После этого стали появляться все больше и больше идей на эту тему, так что пришлось все это упорядочить. Начать я решил с истории развития Искусственного Интеллекта. Статья получилась довольно-таки большой, так что я разделил ее на две части. Вот первая ее часть, посвященная кибернетике.

Приветствую, хабралюди!
На ДР, мне друзья подарили BT-клавиатуру. Маленькая, беленькая, симпатичная, Удобная!
Подключил ее к своему Android 2.3.5 (SGSII), стал с ее помощью лазить по меню, запускать программы, дошел до Вконтакте и решил написать сообщение… а вот переключить на русский язык не смог, но как оказалось позже, это еще были только цветочки! Но кое-что мне удалось. Интересно как?

Начало Windows Phone 8 Development: урок 1. Макет приложения и обработчик событий
Начало Windows Phone 8 Development: урок 2. Доступ к локальному хранилищу приложения
Начало Windows Phone 8 Development: урок 3. Навигация по страницам и передача параметров
Начало Windows Phone 8 Development: урок 4. Связь с сервисами и привязка к данным

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

Сразу же встает два вопроса: возможность использовать SD карту и размер доступного пространства. На первый вопрос ответ — да, использовать SD карту можно. Ответ на второй вопрос — без ограничений. То есть все свободное пространство.

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

Введение

Всем Buenos Dias! В своей статье я хотел бы максимально лаконично и просто рассказать о том, как построить процесс автоматизированного тестирования web-приложения с нуля. Первым делом нужно правильно расставить приоритеты и выбрать приемлемое соотношение цена/качество. Сразу определимся — это будет не решение «на коленках» из зоопарка скриптов, которыми часто пользуются при ручном тестировании. В тоже время мы не будем тратить много усилий на проектирование нашего «фреймворка» для автоматизации. Наша цель — предоставить результаты своей бурной деятельности перед руководством в максимально короткие сроки, при этом система должна быть:

• максимально простой, чтобы тесты могли писать даже специалисты по ручному тестированию
• гибкой и расширяемой, поскольку мы не можем адекватно оценить весь объем работ на данном этапе
• кроссплатформенной (Selenium WebDriver C# поддерживает Firefox, Chrome и IE)

В своем примере я буду успользовать .NET (Microsoft Unit Testing Framework) и Selenium WebDriver C#.

Введение

Снова здравствуйте! Представляю вам вторую часть статьи на тему автоматизированного тестирования веб-приложения на Selenium и C#. И если первая часть была из разряда «капитан очевидность», что вызвало негодование у читателей, то в этой части будет много кода. И так, зачем же писать обертку (wrapper) над Selenium API? На мой взгляд, пользователи могут столкнуться со следующими проблемами:

• Интерфейс IWebDriver предоставляет довольно скудную функциональность в плане управления браузером. Поэтому все, что нам понадобится, придется писать самим
• Описание элемента происходит одновременно с его поиском, т.е. на момент определения элемента он должен существовать в браузере. Очень часто решается путем написания getter для каждого элемента. Это накладно и плохо с точки зрения производительности
• ISearchContext.FindElements принимает только один параметр типа OpenQA.Selenium.By, т.е. мы не можем искать сразу по нескольким свойствам. Обычно элемент ищется по первому критерию, а затем начинается отсеивание по остальным
• Отсутствие многих, казалось бы, очевидных методов и свойств. Например: Exist, SetText, Select, SetCheck, InnerHtml и т.д. Вместо этого мы вынуждены довольствоваться Click, SendKeys и Text
• Множество проблем на различных браузерах, например на Firefox и Chrome элемент кликается, а на IE — нет. Приходится писать special cases, «костыли»
• Производительность. Да, драйвера работают не быстро. Впереди планеты всей как обычно IE — поиск может занимать секунды, иногда и десятки секунд

Ну что ж, много проблем — много решений. Я не хочу и не смогу изложить все и сразу в этой части. Длинный пост будет неинтересен, да и во время его написания энтузиазм резко падает) Поэтому эта часть имеет номер 2.1, в ней я покажу свой wrapper над браузером.

Наверное, уже не существует веб разработчика, который не слышал о Ajax. Microsoft в такой ситуации не может оставаться в стороне, с каждым релизом старается облегчить жизнь именно нам, ASP.NET MVC разработчикам. Но прежде чем я продолжу статью, немного отступлюсь от темы.

Когда я познакомился с MVC фреймворком, он был тогда только во второй версии и, столкнувшись с такими хелперами как @Ajax...., честно говоря, их реализация на стороне клиента меня не впечатлила. Нет, так нет, подумал я про себя, у меня есть jQuery со своим $.ajax, мне его за глаза. Вот и забыл я про них на несколько лет, к своему великому сожалению проморгав этот момент с третьим релизом. Что было, то было. Благо что взялся за ум и почитал две книги по MVC 4. Далее расскажу, как можно сократить написание строк кода благодаря хелперам, упомянутым мною выше.

Начну с того, что MVC может работать с двумя вариантами Ajax библиотек (конечно я же имею ввиду с коробки, не более того) — jQuery и Microsoft Ajax. Чтобы знать, для какого адаптера создавать разметку, существует настройка в web.config UnobtrusiveJavaScriptEnabled и соответствующее значение true (для работы с jQuery) и false (для работы с Microsoft Ajax). Если же нам необходимо поменять значение только для одного представления, можно воспользоваться методом — @{Html.EnableUnobtrusiveJavaScript(bool);}. Хочу обратить внимание, что данная настройка влияет и на формирование валидационных данных на стороне клиента.

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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

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

Посвящается тем 45% .NET разработчиков, что до сих пор сидят на фремворках 2.0-3.5.

Да, вы не ослышались. async и await во втором дотнете. Но обо всём по порядку.

Зачем?

В какой-то момент мне надоело вручную возиться с написанием асинхронного кода. Async/awat выглядели слишком вкусными, чтобы не попробовать. Зная, что Microsoft при добавлении новых возможностей в язык и компилятор не привязывает их жёстко к фреймворку (так, extension-методы и LINQ отлично можно использовать во втором .NET, если где-нибудь объявить System.Runtime.CompilerServices.ExtensionAttribute), и видя Async CTP, добавляющего возможность использования async/await в 2010-ую студию при использовании в качестве целевого фреймворка .NET 4.0, я подумал, а почему бы и нет?

Доброго времени суток.

Хочу обратить ваше внимание на пару скриптов для работы со SkyDrive в Linux. Скрипты написаны на Python и скорее всего будут работать в любой *NIX системе, и не только *NIX. Первый предоставляет возможность работать с аккаунтом в командной строке, второй, модуль для FUSE, позволяет подключить содержимое SkyDrive к файловой системе. Проект практически нигде не упоминается. Сам я на него наткнулся случайно, после того, как не смог подключить SkyDrive с использованием недокументированного WebDAV. И стал искать другой способ подключения, исходя из предположения, что, раз у SkyDrive есть API, то кто-нибудь должен этим воспользоваться.

Вот несколько необычных фактов о языке C#, о которых знают лишь немногие разработчики.

1. Индексаторы могут использовать params параметры

Мы все знаем, как обычно выглядят индексаторы x = something["a"], а так же код необходимый для его реализации:

public string this[string key]
 {
   get { return internalDictionary[key]; }
 }

Но знали ли вы, что для доступа к элементам вы можете использовать params параметры x = something["a", "b", "c", "d"]?
Просто напишите ваш индексатор следующим образом:

Предлагаем вашему вниманию очередную подборку с ссылками на новости, интересные материалы и полезные ресурсы.

Миниатюрный роутер TP-Link TL-WR703N стал эдаким преемником знаменитого D-Link DIR-320 — в сети можно найти немало конструкций на базе этого девайса, вроде роботов с веб-камерой и управлением через веб-интерфейс, приемников интернет-радиостанций и т.д. Я же заказывал его для использования именно по прямому назначению, но руки все равно зачесались внести какое-нибудь изменение в конструкцию — так и родилась идея встроить в корпус дисплей для вывода системной информации. Под катом — мало текста и много фотографий)

Недавно мне довелось разобраться и устранить несколько утечек памяти в популярном фреймворке Торнадо. Не беда, если вы никогда его не использовали, потому что описанное будет мало связано с ним. Рассказать я хочу о методах, которые я использовал для поиска и устранения утечек.

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

Это схема отлично работает до тех пор, пока не появляются объекты, ссылающиеся друг на друга. Самый простой пример — узлы какого-то дерева, хранящие ссылки на свои дочерние и родительский узлы. Узлы продолжат ссылаться друг на друга, даже когда не останется других внешних ссылок ни на один из них. Самое неприятное, что такие узлы могут ссылаться на какие-то другие данные и не давать их освободить. Чтобы устранить такие циклические ссылки, в Питоне существует второй механизм освобождения памяти — сборщик мусора. Он запускается время от времени, ставя выполнение остального кода на паузу, и анализирует все неосвобожденные объекты.

Формально, циклические ссылки нельзя назвать утечками: сборка мусора рано или поздно уничтожит такие объекты. Беда только в том, что Питон не может сам определить, когда еще рано, а когда уже поздно. В моем случае система просто прибивала процесс с Питоном, если сборка мусора не начиналась вовремя.