В статье речь идёт о проблемах с питанием/батареей для этого планшета такого вида:
во время обычной работы планшета начинают происходить события

1. Во время работы показатель заряда батареи перестаёт меняться
2. При блокировке экрана на шторке в правом нижнем углу исчезает показатель заряда батареи
3. В диспетчере задач устройство «Батарея» более не отображается
4. По прошествии времени планшет «внезапно» отключается. После подключения зарядного устройства на кнопке включения мигает красный светодиод, сообщая о полном опустошении батареи
5. После зарядки и загрузки планшет продолжает сбоить

Как оказалось, причиной этому является аппаратная проблема с данной моделью планшетов Lenovo.

Изображение: shutterstock

Вот и настал момент, которого, возможно, больше всего боялись системные архитекторы, инженеры и специалисты по безопасности компании Intel: была найдена ошибка в неперезаписываемой области памяти (ROM) подсистемы Intel Converged Security and Management Engine, и эта ошибка ставит под сомнение все усилия компании по созданию корня доверия и фундамента безопасности на ее платформах.

И дело здесь даже не в том, что ошибки микропрограммного обеспечения (firmware), которое «зашито» в бортовой памяти Mask ROM микропроцессоров и чипсетов, уже невозможно исправить, а скорее в том, что найденная ошибка разрушает цепочку доверия всей платформы в целом, позволяя скомпрометировать ее аппаратную основу.

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

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

Вот пример одной из них:

/* Простое число — целое положительное число, имеющее только два делителя: 1 и само себя */
function isPrimeNumber(number) {
    /* необходимо реализовать функцию, возвращающую true в случае, если number является простым числом и false в противном случае */
}

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

Ругательства — это важная часть любого языка. Правильно и к месту материться — это настоящее искусство, которым далеко не все владеют на своем родном языке.

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

Computer Science клуб — это открытые лекции по компьютерным наукам в Санкт-Петербургском отделении Математического института РАН. Филиалы CS клуба действуют в Новосибирске и Казани.

Основная цель клуба — рассказывать о современном положением дел и знакомить с открытыми задачами в различных областях computer science. Например, вот курсы весеннего семестра в Петербурге одной картинке.



Все курсы открыты для посещения, вход свободный, регистрация не нужна.

Всем привет. 26 февраля в OTUS стартовали занятия в новой группе по курсу «MS SQL Server разработчик». В связи с этим я хочу поделиться с вами своей публикацией про оконные функции. Кстати, в ближайшую неделю еще можно записаться в группу ;-).

---

Оконные функции прочно вошли в нашу практику, но мало кто знает как работают фреймы RANGE и ROWS.

Возможно поэтому они несколько реже встречаются. Цель этой статьи привести примеры использования, чтобы у вас точно не осталось вопросов “Кто есть кто?” и “Как это применять?”. Вопрос “Зачем?” в статье останется не освещенным.

Давайте разберемся что такое фрейм, и как схожего эффекта достичь с помощью ORDER By в предложении OVER().

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

Сравню FreeBSD с GNU/Linux системами. Всё это исключительно субъективное мнение! Многое это просто мой опыт. Почти 100% всего времени я провожу за компьютером и исключительно Unix системами, примерно поровну с FreeBSD и GNU/Linux, вот уже 20+ лет.

Большая часть достоинств FreeBSD также относится и к другим популярным свободным BSD системам: NetBSD, OpenBSD, DragonflyBSD. Что-то в этих системах будет получше, многое появилось впервые не в FreeBSD, но перекочевало в неё. FreeBSD многое наследует от NetBSD (различные драйвера и подсистемы), от OpenBSD (сетевые технологии), DragonflyBSD (лучшая масштабируемость на многопроцессорных платформах), от Solaris (DTrace, идея Jail-ов, ZFS), сочетая самое лучшее ото всех.

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

Для тех, кто не знает, SNAFU — персонаж военных патриотических мультфильмов, созданных американцами во время войны. Этот раздолбай, ввиду природного идиотизма, все время попадает в катастрофические ситуации и, как правило, гибнет в конце серии. Правда, в следующей серии он снова оказывается живым — в этом смысле, его можно считать далеким прародителем Кенни из Южного Парка.

При наборе людей на позицию SQL server developer, я часто был покорен тем, как они отвечали на вопросы. Я готов был сказать им ДА, если бы меня не спасала небольшая задача в одну строчку, которую предложил мой коллега. Удивительно, сколько всего может дать эта задача в одну строку SQL. И вот уже кандидат уже с упоением ходит по граблям. А грабель, как вы увидите, там много. Конечно, ни один человек не собрал ВСЕ возможные грабли. Но, чтобы их все показать, мне и понадобился SNAFU.

Не так давно, в городе N одна IT-компания, специализирующаяся на работе с данными клиентов, успешно вела свою работу в своём ДЦ в режиме 24/7. Тот самый случай, когда «сапожник в сапогах», т.е. в IT-компании IT было хорошо отлажено. Интересное началось, когда после многих лет работы свой пост покинул технический директор, который стоял у основ, на котором держался контроль за исправной работой всей IT-вертикали. На смену пришел человек не менее опытный (далее по тексту – “профи”), и даже с более широким кругозором, он буквально очаровал “бизнес” новыми горизонтами развития. Но, как это часто бывает, люди высокого полёта очень неохотно спускаются на землю уровень рядового администрирования.


Хронометраж инцидента:

День первый (апрель): одна местная СХД начала сыпать alert-ами, а потом среди них появились и первые error-ы. Увидев это, админ известил своего руководителя согласно инструкции. Наш профи отмахнулся отпиской ответным письмом, следуя “золотому правилу программиста” – “Работает? Не трогай!”.

Отступление первого дня — Обычно СХД общается с помощью оповещений среди которых стоит выделить Алерты (от “Alert”) – сигналы тревоги. По сути, это оповещения, сигнализирующие о тревожном событии или предупреждающие его. Типы оповещений:
Варнинги (от “Warning”) – предупреждения; как правило дают время спокойно подумать.
Эрроры (от “Error”) – ошибки; например, вылетел диск, но доступ к данным не прервался; здесь уже не стоит откладывать их решение на потом.
Критикал эрроры (от “Critical Error”) – критические ошибки, гарантированно

Что такое структура данных?
Проще говоря, структура данных — это контейнер, в котором хранятся данные в определенной компоновке (формате, или способе организации их в памяти). Эта «компоновка» позволяет структуре данных быть эффективной в одних операциях и неэффективной в других. Ваша цель — понять структуры данных, чтобы вы могли выбрать структуру данных, наиболее оптимальную для рассматриваемой проблемы.

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

Elasticsearch, вероятно, самая популярная поисковая система на данный момент с развитым сообществом, поддержкой и горой информации в сети. Однако эта информация поступает непоследовательно и дробно.

Самое первое и главное заблуждение — "нужен поиск, так бери эластик!". Но в действительности, если вам нужен шустрый поиск для небольшого или даже вполне себе крупного проекта, вам стоит разобраться в теме поподробней и вы откажетесь от использования именно этой системы.

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

Недавно на стендапе коллега внес рацпредложение: автоматизировать сборку релизов, взяв за основу готовые уже наработки по взаимодействию с Jira, написанные на Python.

Процесс деплоя у нас следующий: когда накапливается достаточное количество задач, прошедших тестирование из них собирается Релиз-кандидат (RC) в каждом проекте, затронутом задачами, затем задачи тестируются в составе RC. После этого RC заливается на стейджинг сервер, где в близком к боевому окружении все еще раз тестируется и проводится полный регресс. И затем, после необходимых деплойных действий свежий релиз заливается в мастер.

До недавнего времени весь процесс сборки проводился кем-либо из разработчиков вручную. Что отнимало час, два и больше времени и было, мне кажется, не очень интересным занятием. Теперь же, когда уже почти все готово, релиз из 20 задач, затрагивающий 5 проектов, собирается меньше минуты. Остается, конечно еще разрешение конфликтов, запуск пропущенных тестов и прочее, но даже с учетом этого, времени разработчиков и тестировщиков, вынужденных ждать, пока кто-то и первых освободится и создаст RC, экономится немало.

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

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с использованием стороннего плагина под названием pglogical.

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



TL;DR

• Всё получилось (не без костылей, о них и статья).
• Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
• Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

Многократно вычитывая одни и те же данные, встает вопрос оптимизации, данные не меняются или редко меняются, это различные справочники и др. информация, т.е. функция получения данных по ключу — детерминирована. Тут наверно все понимают — нужен Кеш! Зачем всякий раз повторно выполнять поиск данных или вычисление?

Так вот здесь я покажу как делать кеш в Java Spring и поскольку это тесно связанно скорее всего с Базой данных, то и как сделать это в СУБД на примере одной конкретной.

Содержание

• Кеш в Spring
• Кеш в Oracle PL-SQL функции

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

На сегодняшний день Python является одним из наиболее используемых языков в сфере создания не только непосредственно программных продуктов, но также обеспечения их инфраструктуры. Вследствие этого многим девопсам, по их воле или против оной, пришлось учить новый язык для последующего использования в качестве дополнения к старым добрым Bash-скриптам. Однако Bash и Python исповедуют различные подходы к написанию кода и имеют определенные особенности, в виду чего портирование Bash-скриптов на «змеиный язык» иногда оказывается ёмкой и далеко не тривиальной задачей.

Чтобы упростить жизнь девопсам, создано и продолжает создаваться много полезных библиотек и утилит на Python. Данная статья описывает сразу две новых библиотеки, созданные автором сего поста — smart-env и python-shell — и призванные избавить девопса от необходимости уделять много внимания тонкостям работы с Python, оставляя простор для более интересных задач. Сфера деятельности библиотек — переменные окружения и запуск внешних утилит.

Кого заинтересовало, прошу под кат.

Здравствуйте, Хабр.

Сегодня мы предлагаем вашему вниманию перевод статьи из блога MemSQL, которая исходно является рекламной (посвящена достоинствам MemSQL, обновлена по состоянию на начало января 2020 года). Но мы решили все-таки перевести ее в сокращенном виде, поскольку она подробно объясняет, почему мы пока так и не собрались издавать ничего ни по MongoDB, ни по Cassandra, ни по прочим нереляционным базам данных. Может быть, мы были правы, ограничившись весьма успешной книгой "MySQL по максимуму".

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

Одной из самых проблемных задач для обычного пользователя является резервное копирование под Windows, которое обеспечивало бы закрытие следующих вопросов:

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

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

Однако, уже давно существуют инструменты для решения задачи. Главное правильно применить Unix way и командные файлы. И самый простой вариант — заархивировать файлы в один архив и отправить его в онлайн-хранилище, используя командную строку. Для ускорения работы задача делится на 2 этапа — сначала создается и отправляется в онлайн-хранилище полный архив, потом по мере необходимости создаются инкрементные архивы, что дает скорость. Шифрование архивов обеспечивает безопасность данных.

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

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

Естественно, простота скрипта обернулась и его недостатками, а именно:

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

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