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


Эта статья будет посвещена настройки хоста именно для использования в «быту», т.е. разговор пойдет о GPU PASSTHROUGH.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.

Предисловие переводчика

Всем здравствуйте, вот мы и подошли к конечной части. Приятного чтения!
Навигация:

• Часть 1
• Часть 2
• Часть 3
• Оригинал

Математика многочленов

NumPy предоставляет методы для работы с полиномами. Передавая список корней, можно получить коэффициенты уравнения:

>>> np.poly([-1, 1, 1, 10])
array([ 1, -11,   9,  11, -10])

Здесь, массив возвращает коэффициенты соответствующие уравнению: $$.

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

Но есть темы вечные. Одна из них — Python. Оно и понятно, язык прекрасно подойдёт тем, кто с программированием не знаком вовсе; изучить все основные библиотеки можно за пару недель, а возможности практически не ограничены. Автор блога GeekBrains Илья Бубнов заглянул на электронные полки магазина Amazon, чтобы посмотреть, что полезного было выпущено или перевыпущено по Python в первой половине 2018 года.

Я 10 лет разрабатываю ПО, участвовал в нескольких open source-проектах и в многочисленных не-open source-проектах, работал в больших и малых командах, и везде мы использовали Github в качестве репозитория версионирования.

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

Статистика в последнее время получила мощную PR поддержку со стороны более новых и шумных дисциплин — Машинного Обучения и Больших Данных. Тем, кто стремится оседлать эту волну необходимо подружится с уравнениями регрессии. Желательно при этом не только усвоить 2-3 приемчика и сдать экзамен, а уметь решать проблемы из повседневной жизни: найти зависимость между переменными, а в идеале — уметь отличить сигнал от шума.

Для этой цели мы будем использовать язык программирования и среду разработки R, который как нельзя лучше приспособлен к таким задачам. Заодно, проверим от чего зависят рейтинг Хабрапоста на статистике собственных статей.

Для начала об авторе – я более 20 лет проработал в ИТ в трех компаниях: EMC, IBM, Sun (в алфавитном порядке). Начинал как системный инженер сразу после университета, потом был старшим инженером, техническим консультантом, руководителем технических консультантов и, наконец, техническим директором, руководившим командой пресейлов и архитекторов всего более 70-ти человек. Кроме того, год я был лидером продавцов через партнеров (Channel Sales Leader), распределенных по Центральной и Восточной Европе. Ниже я попытаюсь поделиться своим опытом именно, как руководителя и, дабы не возникало не правильных или не нужных ассоциаций, я буду приводить примеры из практики во время работы на компанию ABC (тоже три буквы). Возможно, изложение несколько однобоко, поскольку все мои работодатели – крупные международные компании, и я работал в их региональных офисах. Ну, тогда с этой спецификой я не могу ничего поделать и то, что читатель сочтет не приемлемым и не правильным пусть и останется таковым персонально для него.

Вступление

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

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

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

Хочу поделиться историей, ну и заодно услышать мнения других участников хабрасообщества. Это небольшая история о том, как агрессивное внедрение методологии разработки Agile (Scrum) в отдельно взятой российской IT компании послужило началом исхода из компании лучших разработчиков. Обычно в статьях про Agile рассказывают, какая это классная и полезная методология, и вообще — это лучшее, что было придумано в этом направлении. Возможно, эта статья поможет взглянуть на Agile с другой стороны, ведь у любой монеты, как оказалось, есть две стороны.

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

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

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

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

Мы пообщались с представителями ИТ-индустрии и попросили высказать свое отношение к таким руководителям, рассказать о преимуществах и недостатках такого управления.

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

На этот раз задача оказалась предельно простая и прагматичная, но ее решение дает далеко идущие последствия.

Кейс

Суть задачи в следующем:

Для создания программного обеспечения нужны программисты. К сожалению, их труд стоит дорого, они ленивы и их почти невозможно контролировать. Независимо от того, насколько хорошо работают их программы, вы должны платить им каждый месяц, и, конечно, чем меньше вы платите, тем лучше. Однако, иногда сотрудники догадываются, что им недоплачивают и уходят. Как этому помешать? Жаль, что сегодня нет возможности заставлять их работать насильно. Есть несколько техник, которые помогут платить программистам меньше, и я хочу о них рассказать.

1 Почему JavaScript отстой
• 1.1 Плохая конструкция
• 1.2 Система типов
• 1.3 Плохие функции
• 1.4 Отсутствующие функции
• 1.5 DOM
2 Почему Lua отстой
3 Почему PHP отстой
• 3.1 Исправлено в поддерживаемых в настоящее время версиях
4 Почему Perl 5 отстой
5 Почему Python отстой
• 5.1 Исправлено в Python 3
6 Почему Ruby отстой
7 Почему Flex/ActionScript отстой
8 Почему скриптовые языки отстой
9 Почему C отстой
10 Почему C++ отстой
11 Почему .NET отстой
12 Почему C# отстой
13 Почему VB.NET отстой
15 Почему Objective-C отстой
16 Почему Java отстой
• 16.1 Синтаксис
• 16.2 Исправлено в Java 7 (2011)
• 16.3 Модель
• 16.4 Библиотека
• 16.5 Обсуждение
17 Почему Backbase отстой
18 Почему XML отстой
19 Почему отстой XSLT/XPath
20 Почему CSS отстой
• 20.1 Исправлено в CSS3
21 Почему Scala отстой
22 Почему Haskell отстой
23 Почему Closure отстой
24 Почему Go отстой
• 24.1 Базовые средства программирования (базовый язык)
• 24.2 Взаимосовместимость
• 24.3 Стандартная библиотека
• 24.4 Набор инструментальных средств
• 24.5 Сообщество
25 Почему Rust отстой
• 25.1 Безопасность
• 25.2 Синтаксис
• 25.3 Конструкция API и система типов
• 25.4 Сообщество
• 25.5 Набор инструментальных средств

Почему JavaScript отстой

Учтите, что некоторые положения относятся не к самому JavaScript, а к программным интерфейсам веб-приложений (https://developer.mozilla.org/en/docs/Web/API).

Плохая конструкция

• Каждый скрипт исполняется в едином глобальном пространстве имён, доступ в которое возможен в браузерах с оконным объектом.
• Camel-регистр никуда не годится:

XMLHttpRequest
HTMLHRElement

Совсем недавно я стала счастливым обладателем сертификата PMP — Project Management Professional. И в этой статье я хочу поделиться своим опытом со всеми, кому предстоит этот экзамен, кто еще только думает сдавать или не сдавать, ну и с теми кому просто интересна эта тема.

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

Можно ли войти в одну реку дважды?

Данная статья написана по результатам доклада на конференции Нефтегазстандарт – 2016, сделанная мной от имени компании ТриниДата.

Работая инженером — онтологом, я занимаюсь созданием информационных моделей для информационных систем.

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

Так получилось, что я начал работать с PostgreSQL три года назад и за это время умудрился методично собрать все возможные грабли, которые можно вообразить. И сказать по правде, если бы была возможность поделиться с собой трехлетней давности нынешним горьким опытом, моя жизнь была бы куда проще и нервные клетки целее. Именно поэтому я решил написать абсолютно субъективную статью со сводом правил, которых придерживаюсь при разработке на PostgreSQL. Возможно, кому-то эта статья поможет обойти собранные мной грабли (и наступить на другие, ха-ха!).

Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код

Цель этой публикации — поделиться опытом работы над проектом со сложной историей и тяжёлым наследием. После ухода из очередного т.н. «стартапа», я решил что хочу попробовать новых ощущений: enterprise, legacy, etc. Для этого взялся за работу над корпоративным приложением для транснационального концерна. Разработка на тот момент шла уже третий год, приложение пережило несколько поколений разработчиков, но стабильного релиза так и не было.

Полагаю публикация будет полезной:

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

Затрагиваемые в статье вопросы:

• Низкая компетенция разработчиков, и что с этим можно поделать?
• Какие аргументы убедительны в глазах заказчика для нефункциональных изменений в проекте?
• Почему работа аналитиков и QA очень важна с точки зрения разработки в частности и для проекта в целом?

Здрасте!
Множество информации по SEO (оптимизация, продвижение, вот это вот все) разбросано по просторному интернету, создано множество статей и форумных топиков на эту тему. В данном посте, я собрал рекомендации и инструменты, которые касаются непосредственной страницы сайта (структура, код, вот это вот все).

В статье вы найдете:

• структурные элементы страницы: заголовки, картинки, URL, контент. Рекомендации по их использованию и оценки важности в ранжировании.
• микроразметка: кто она и с чем ее едят. Рассмотрены schema.org и OpenGraph
• дана оценка инструментам с точки зрения важности для ранжирования, usability или же поведенческих факторов
• на примере крупный процветающих сайтов рассмотрены примеры использования описанного инструментария

Статья носит образовательный характер, и поэтому даже если вы собаку съели в данной области, можете зайти и оставить свой профессиональный комментарий и оценку содержания поста.

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