Ad-social Bot

Smmok Bot

Vkserfing Bot

Vkstorm Bot

Vktarget Bot

Все программы

Запись опубликована: 23.02.2018

Привет, меня зовут Pavel Germanika

Спасибо, что зашли на мой сайт! Хочу рассказать немного о себе и о том, что вы cможете найти для себя полезного на страницах моего блога.


 

Может ли человек, проживая в унылом бесперспективном городе, чего-то добиться, имея под рукой лишь старый ноутбук и интернет? Можно ли без всяких офисов, начальных капиталов построить компанию, приносящую неплохую прибыль? Ответ на этот вопрос вы сможете узнать в моем блоге. Я Pavel Germanika, добро пожаловать!

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

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

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

Мой Блог — это реалити-шоу обычного заурядного парня, который пытается добиться успеха с полного нуля. Никакого начального капитала, никаких знакомств, никаких особых способностей. Только идеи, анализ и компьютер. Я хочу быть максимально открытым и делиться с вами всеми своими мыслями и результатами работы.

Я очень надеюсь на то, что найдутся люди, которым мои записи окажутся полезными. Я таю надежду, что для кого-то мой блог станет мотивацией начать что-то делать или что кто-то почерпнет здесь знания и идеи.

Любой из вас может связаться со мной. Я рад каждому! Пишите на мой Telegram.

Метки: ,





Запись опубликована: 25.03.2019

[Перевод] Чего мне никогда не говорили о CSS

  • Перевод

Фото Джантин Дурнбос на Unsplash
Это ни в коем случае не критика коллег, а всего лишь краткий список важных вещей, которые я самостоятельно узнала о CSS в последнее время.
Не секрет, что многие разработчики, похоже, не думают о CSS. Это легко заметить по обсуждениям в интернете и в разговорах с друзьями и коллегами. Тем не менее, многие знания мы получаем именно от коллег, и иногда я понимаю, что о некоторых важных нюансах CSS мне никто не рассказал, потому что люди просто не тратят время на изучение этой темы.
Чтобы исправить это, я провела некоторые исследования и составила небольшой список понятий, которые считаю интересными и полезными для лучшего понимания и написания CSS.
Этот список определённо не исчерпывающий. Он содержит только новое, что я узнала за последние несколько дней и чем хочу поделиться, вдруг это поможет кому-то ещё.

Терминология

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

Комбинатор потомков

Видели пробел между селекторами в вашем стиле? На самом деле у него есть название, это комбинатор потомков (descendant combinator).


Комбинатор потомков

Макет, отрисовка и композиция

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

1. Макет (layout)

Шаг макетирования — это расчёт, сколько места элемент занимает на экране. Изменение свойства ‘layout’ в CSS (например, ширина, высота) означает, что браузеру придётся проверить все остальные элементы и перерисовать страницу, то есть перекрасить затронутые области и наложить их друг на друга.

2. Отрисовка (paint)

Этот процесс заполняет пикселями все визуальные части элементов (цвета, границы и т. д.). Отрисовка элементов обычно выполняется на нескольких слоях.

Изменение свойства ‘paint’ не влияет на макет, поэтому браузер пропускает шаг макетирования, но всё равно делает отрисовку.

На отрисовку зачастую уходит больше всего времени при рендеринге.

3. Композиция (composite)

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

Если вы измените свойство CSS, которое не затрагивает ни макет, ни отрисовку, то браузеру остаётся сделать только композицию.

Для подробной информации, какие процессы запускают различные свойства CSS, см. триггеры CSS.

Производительность CSS

Селектор потомков может дорого обойтись

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

Например:


Пример селектора потомков

Браузеру придётся оценить все ссылки на странице, прежде чем перейти к тем, которые находятся внутри нашего раздела #nav.

Более эффективный способ — добавить конкретный селектор .navigation-link на каждую ссылку <a> внутри раздела #nav.

Браузер считывает селекторы справа налево

Кажется, я должна была раньше узнать эту важную вещь, но я не знала… При парсинге CSS браузер разбирает селекторы справа налево.

Рассмотрим следующий пример:


Браузер читает справа налево

Шаги:

  • сопоставить все <a> на странице;
  • найти все <a>, содержащиеся в <li>;
  • взять совпадения и сузить их до тех, которые содержатся в <ul>;
  • наконец, отфильтровать вышеупомянутый выбор до тех, которые содержатся в элементе с классом .container.

Глядя на эти шаги, мы видим, что чем более конкретным является правый селектор, тем более эффективно браузер сможет фильтровать и применять свойства CSS.

Чтобы улучшить производительность приведённого примера, мы могли бы заменить .container ul li a, добавив что-то вроде .container-link-style на самом теге <a>.

По возможности не изменяйте макет

Изменения некоторых свойств CSS требуют обновления всего макета.

Например, геометрические свойства width, height, top, left требуют заново рассчитать макет и обновить дерево рендеринга.

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

Будьте осторожны со сложностью отрисовки

Некоторые свойства CSS (например, размытие) обходятся дороже других, когда дело доходит до отрисовки. Подумайте о более эффективных способах достижения того же результата.

Дорогие свойства CSS

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

Некоторые из дорогих свойств:

  • border-radius
  • box-shadow
  • filter
  • :nth-child
  • position: fixed

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

Порядок (ordering)

Порядок имеет значение

Посмотрим на такой CSS:

А затем посмотрим на HTML-код:

Порядок селекторов в HTML не имеет значения, а в CSS — имеет.

Хороший способ оценить производительность CSS — использовать инструменты разработчика в браузере.

В Chrome или Firefox можете открыть инструменты разработчика, перейти на вкладку «Производительность» и записать, что происходит при загрузке или взаимодействии с вашей страницей.


Скриншот вкладки «Производительность» в Chrome

Ресурсы

Исследуя тему для этой статьи, я наткнулась на некоторые действительно интересные инструменты, перечисленные ниже:

CSS Triggers — веб-сайт, перечисляющий некоторые свойства CSS и как они влияют на производительность.

Uncss — инструмент для удаления неиспользуемых стилей из CSS.

Css-explain — небольшой инструмент, объясняющий селекторы CSS.

Fastdom — инструмент пакетных операций чтения/записи DOM для ускорения производительности макета.

Пока всё! Надеюсь, это имеет смысл!

Платежная система

Поделиться публикацией

Source: habr1

Метки:





Запись опубликована: 25.03.2019

Swift 5.0. Что нового?



Авито

196,00

У нас живут ваши объявления

Swift 5 — долгожданный релиз, включающий в себя несколько десятков улучшений и исправлений. Но самой главной целью релиза Swift 5.0 было достижение ABI стабильности. В этой статье вы узнаете, что такое ABI и что стабильный ABI даст iOS/macOS разработчикам. А также проведём разбор нескольких новых фич Swift 5.

ABI Stability

ABI — бинарный интерфейс приложения. ABI можно рассматривать как набор правил, позволяющих компоновщику объединять откомпилированные модули компонента.

Соответственно, в ABI описано следующее.
1). То, как происходит вызов кода из разных модулей, в том числе системных.
2). Формат передачи аргументов и получение возвращаемого значения из функций.
3). Алгоритмы лэйаута данных в оперативной памяти.
4). Управление памятью, ARC.
5). Система типов, дженерики.

Swift 5 вместе со стабильным ABI предоставляет бинарную совместимость для приложений. Бинарная совместимость для iOS/macOS приложений означает, что скомпилированные приложения будут в рантайме совместимы с системными библиотеками, скомпилированными более ранними или более поздними версиями языка. Например, приложение, скомпилированное с Swift 5.0, будет совместимо с стандартными библиотеками, скомпилированными с Swift 5.1 или Swift 6.0.

Начиная с iOS 12.2 и macOS 10.14.4, операционные системы Apple будут содержать все необходимое для запуска свифтовых приложений. Это означает, что приложения, написанные на Swift 5 и более поздних версиях, не будут содержать рантайм и стандартную библиотеку языка. Поэтому приложения, написанные на Swift 5, станут весить примерно на 3-10 мегабайт меньше.

Важно отметить, что помимо ABI stability, есть еще Module stability. Если ABI stability позволяет совмещать разные версии свифта в рантайме, то Module stability отвечает за то, как компилируются бинарные фреймворки, написанные на разных версиях языка. Module stability появится в Swift 5.1. И тогда разработчики смогут распространять свои фреймворки не только с открытым исходным кодом, но и в скомпилированном виде.

Плюсы ABI стабильности.

1). Приложения станут весить меньше.
2). Ускорение запуска и производительности приложений.
3). В теории, Apple может писать новые фреймворки полностью на Swift.

Минусы ABI стабильности.

Разработчикам придётся учитывать отсутствие в более старых версиях стандартной библиотеки какого-либо нового функционала. Например, если в iOS 13 будет встроен Swift 5.1 с какими-нибудь новыми классами/функциями в стандартной библиотеке, то при поддержке в приложении iOS 12.2 разработчики не смогут их использовать. (Нужно будет вставлять проверки #available(…) так же, как мы это делаем сейчас для Foundation, UIKit и других платформенных библиотек).

Тип Result в стандартной библиотеке

В стандартной библиотеке появился удобный способ передачи и обработки ошибок в асинхронном API. Также этот тип можно использовать в случае, если по каким-либо причинам нам не подходит стандартная обработка ошибок через try/catch.

Тип Result реализован через enum с двумя кейсами: success и failure:

public enum Result<Success, Failure> where Failure: Error {
    case success(Success)
    case failure(Failure)
    ...
}

На самом деле такой подход не нов для Swift-разработчиков. Ещё со времен первой версии Swift многие разработчики использовали похожий подход. Но теперь, когда в стандартной библиотеке появился свой Result, это упростит взаимодействие с кодом из внешних библиотек.

Пример использования в сервисе загрузок статей:

struct Article {
    let title: String
}
class ArticleService {
    func fetchArticle(id: Int64, completion: @escaping (Result<Article, Error>) -> Void) {
        // асинхронная загрузка статьи
        // ...
        completion(.success(Article(title: "Swift 5.0. Что нового?")))
    }
}

А вот пример обработки полученного результата. Так как Result — это всего лишь enum, то мы можем обработать все его состояния с помощью switch:

articleService.fetchArticle(id: 42) { result in
    switch result {
    case .success(let article):
        print("Success: (article)")
    case .failure(let error):
        print("Failure: (error)")
    }
}

Raw strings

В Swift 5 добавили так называемые raw strings, в которых кавычки и бэкслеш интерпретируются именно как символы, и для их использования в литерале не нужно использовать символ экранирования. Чтобы написать литерал такой строки, необходимо к двойным кавычкам по краям добавить символ #.

Пример использования кавычек:

// swift 4.2
print("Чтобы вывести строку в "кавычках" необходимо добавлять бэкслеш.")
print("Чтобы добавить переход на следующую строку, нужно использовать символы n")
// swift 5
print(#"В "сырой" строке не нужны бэкслеши перед кавычками"#)
print(#"Чтобы добавить переход на следующую строку, нужно использовать символы n"#)

Эта фича особенно полезна при написании регулярных выражений:

// swift 4.2
let regex = "^(*d{3})*( |-)*d{3}( |-)*d{4}$"
// swift 5
let regex = #"^(*d{3})*( |-)*d{3}( |-)*d{4}$"#

Для интерполяции строк после бэкслеша надо добавлять символ #:

// swift 4.2
let string = "Строка с интерполяцией (variable)"
// swift 5
let string = #"Строка с интерполяцией #(variable)"#

Более подробно можете прочитать в этом предложении.

Обновленная интерполяция строк

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

extension DefaultStringInterpolation {
    mutating func appendInterpolation(price: Decimal) {
        let formatter = NumberFormatter()
        formatter.numberStyle = .currency
        if let string = formatter.string(from: price as NSDecimalNumber) {
            appendLiteral(string)
        } else {
            appendLiteral(price.description)
        }
    }
}
print("Price of item: (price: 9.99)")
// Price of item: $9.99

Важно отметить то, что, по сути, конструкция (price: 9.99) в строке с помощью компилятора преобразовалась в вызов метода appendInterpolation(price: Decimal).
Также в методах appendInterpolation мы можем добавить неограниченное число аргументов, как именованных, так и не именованных, с дефолтными значениями или без них.

Более подробно можно прочитать в этом предложении.

Проверка кратности чисел

К числовым типам в стандартной библиотеке добавлен метод проверки кратности isMultiple(of:). Да, мы всё ещё можем использовать оператор взятия остатка от деления %. Но, кажется, isMultiple(of:) выглядит более наглядно.

let interger = 42
if interger.isMultiple(of: 3) {
    print("Кратно трем")
} else {
    print("Не кратно трем")
}

Метод compactMapValues в Dictionary

Метод compactMapValues позволяет преобразовать значения словаря, а также отфильтровать их, если само преобразование возвратило nil.

Например, маппинг строковых ключей в тип URL:

let dict = [
    "site": "https://www.site.ru/path/to/web/site/page",
    "other site": "invalid url"
]
let mappedDict: [String: URL] = dict.compactMapValues { URL(string: $0) }
print(mappedDict)
// ["site": https://www.site.ru/path/to/web/site/page]

Вторая пара «ключ/значение» была удалена после маппинга, так как строка не является валидным URL’ом.

Изменение поведения try?

В Swift 4.2 с помощью конструкции try? можно с лёгкостью получить опциональный тип с несколькими уровнями вложенности. В большинстве случаев это не то, чего ожидает разработчик. По этой причине в Swift 5 try? получил поведение, схожее c optional chaining. То есть при комбинации try? с optional chaining или optional casting результатом выражения будет опционал с одним уровнем вложенности.

Пример использования try? вместе с as?:

// Swift 4.2
let jsonDict = try? JSONSerialization.jsonObject(with: data, options: []) as? [String: Any]
// Тип jsonDict - [String: Any]??
// Swift 5
let jsonDict = try? JSONSerialization.jsonObject(with: data, options: []) as? [String: Any]
// Тип jsonDict - [String: Any]?

Пример использования try? вместе с методом опционального объекта:

// Swift 4.2
let article = try? storage?.getArticle()
// Тип article - Article??
// Распаковка
if let first = article, let second = first {
    first // тип Article?
    second // тип Article
}
// Или так
if case let value?? = article {
    value // тип Article
}
// Swift 5
let article = try? storage?.getArticle()
// Тип article - Article?
// Распаковка
if let value = article {
    value // тип Article
}

Более подробно можно прочитать в этом предложении.

Атрибут @dynamicCallable

Новый атрибут @dynamicCallable позволяет пометить тип как «вызываемый». Это означает, что мы сможем вызвать тип как обычный метод.
Если мы помечаем тип как @dynamicCallable, то должны реализовать один (или оба) из методов:

func dynamicallyCall(withArguments: <#Arguments#>) -> <#R1#>
func dynamicallyCall(withKeywordArguments: <#KeywordArguments#>) -> <#R2#>

Тип Arguments должен поддерживать протокол ExpressibleByArrayLiteral, тип KeywordArguments должен поддерживать протокол ExpressibleByDictionaryLiteral, а R1 и R2 могут быть любыми типами.

Например, структура Sum. При её вызове можно передать любое количество чисел и получить их сумму:

@dynamicCallable
struct Sum {
    func dynamicallyCall(withArguments args: [Int]) -> Int {
        return args.reduce(0, +)
    }
}
let sum = Sum()
let result = sum(1, 2, 3, 4)
print(result) // 10

По сути, компилятор преобразует sum(1, 2, 3, 4) в вызов sum.dynamicallyCall(withArguments: [1, 2, 3, 4]). Аналогично для метода dynamicallyCall(withKeywordArguments:).

Эта фича позволит добавить взаимодействие Swift кода с различными динамическим языками программирования, например, Python или JavaScript.

Более подробно можно прочитать в этом предложении.

Поддержка оператора «меньше» в директивах проверки версии компилятора и языка

Начиная с 5-ой версии Свифта можно использовать оператор «меньше» при проверках версии компилятора в коде:

// Swift 4.2
#if !swift(>=4.2)
// Этот код будет скомпилирован только для свифт 4.2 и меньше
#endif
// Swift 5
#if swift(<5)
// Этот код будет скомпилирован только для свифт 4.2 и меньше
#endif

Заключение

Это не все возможности и улучшения появившиеся в Swift 5. Всего было принято 28 предложений от комьюнити, также включающие в себя повышение производительности строк, улучшения Swift Package Manager и стандартной библиотеки. Полный список изменений и улучшений можно посмотреть в release notes.

Теги:

Похожие публикации

Source: habr1

Метки:





Запись опубликована: 25.03.2019

Security Week 13: открытые пароли в Facebook

У Facebook проблема с безопасностью пользовательских данных. Опять? Да сколько можно! 19 марта журналист Брайан Кребс сообщил, что компания годами хранила пароли пользователей в открытом виде (новость, статья Кребса, официальное сообщение Facebook). Судя по официальному заявлению и по данным Кребса (полученным от сотрудника компании, пожелавшего остаться анонимным), база открытых паролей образовалась в результате действий разработчиков.

Пароль от вашей учетной записи с высокой вероятностью был в этой базе, если вы пользовались приложением Facebook Lite, но возможны и другие варианты. Facebook планирует уведомить всех пострадавших индивидуально, предложив сменить пароль, — это «десятки миллионов» пользователей Facebook и Instagram.
База данных была обнаружена в ходе регулярного аудита безопасности и существовала предположительно с 2012 года. Пользователи соцсети пострадали условно: в Facebook утверждают, что никакой подозрительной активности (утечки базы или неправомерного доступа со стороны инсайдеров) зафиксировано не было. Тем не менее, по данным Кребса, полученным из анонимного источника, внутри компании было зафиксировано более 9 миллионов обращений к базе паролей от двух тысяч разработчиков.

В общем, к этой ситуации очень хорошо подходит цитата из фильма:

Такая резко отрицательная оценка ситуации с безопасностью в Facebook возможна только на фоне прочих неприятностей социальной сети. Все началось со скандала с массовым профилированием пользователей сторонней фирмой Cambridge Analytica в 2018 году. После этого было обнаружено много особенностей работы Facebook, которые было бы неплохо усовершенствовать в контексте приватности данных пользователей. Это и проблемы с модерацией контента, и эксплуатация рекламной системы, которая позволяет таргетировать людей по номерам телефонов, и многое другое. Шестого марта основатель сети Марк Цукерберг анонсировал радикальные изменения в соцсети, которая в будущем должна стать «сфокусированной на приватности». Это похвально, хотя не стоит забывать, что бизнес-модель соцсети (да и любого другого бесплатного сетевого сервиса) по-прежнему зависит от продажи персональных данных пользователей рекламодателям в том или ином виде.

Так вот, если от этого всего отвлечься, то проблема с паролями не выглядит настолько ужасной — просто потому, что подобные неполадки регулярно возникают у многих сервисов. В прошлом году компания Twitter попросила сменить пароль у 330 миллионов пользователей — выяснилось, что пароли открытым текстом, до хеширования, сохранялись во внутренних логах соцсети. Аналогичная проблема с логами произошла и у Github. Instagram недавно внедрил возможность загрузки всех данных пользователя (согласно требованиям GDPR) так, что пароль на определенном этапе и вовсе передавался прямо в составе URL.

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

Требования, которые понемногу начинают предъявлять к крупным организациям, таким как Facebook, Google и Apple, оказываются серьезнее, чем к более мелким компаниям, — из-за масштаба. Даже небольшая проблема или недоработка в их случае затрагивает количество пользователей, равное населению не самой маленькой страны. Судя по всему, важнее становится даже не безопасность учетной записи отдельного пользователя, а приватность пользователей в целом. Каждое сообщение из серии «опять что-то пошло не так» заставляет задуматься: а что они про нас еще знают? К каким данным имеют доступ? Как их используют?

И дело не только в том, что вам показывают рекламу когтеточек, если вы регулярно пишете про котиков. Мы даже еще не знаем, к чему приведет широкая доступность пользовательских данных в сети. Относительно небольшой (там не упоминался Facebook, поэтому никто не заметил) скандал произошел недавно вокруг алгоритма распознавания лиц компании IBM. Выяснилось, что для тренировки использовалась база данных пользовательских фото с Flickr. С юридической точки зрения все чисто, фото распространялись по лицензии Creative Commons. Кажется, поколение пользователей интернета начала двухтысячных будет самым задокументированным: до этого не было технологий, после — уже не позволят вновь разрабатываемые нормы приватности. То, что на базе наших с вами данных развиваются технологии — хорошо. Хотелось бы избежать ситуации, когда накачанные информацией алгоритмы знают пользователей лучше, чем они сами, и используют это не только для невероятно умных и полезных сервисов, но и для манипуляции.

Источник.

Source: habr1

Метки:





Запись опубликована: 25.03.2019

«Галоп пикселя — часть пятая» — Анимация персонажей. Ходьба

  • Tutorial


«Галоп пикселя» — часть 1 (линк)
«Галоп пикселя» — часть 2 (линк)
«Галоп пикселя» — часть 3 (линк)
«Галоп пикселя» — часть 4 (линк)
«Галоп пикселя» — часть 5 (линк)
Доброго времени суток Хабр. Мы продолжаем цикл «Галоп Пикселя». Сейчас, находясь на старте 2019 года, можно с уверенностью говорить, что это не только цикл статей, но и многолетняя сага. Пространное повествование о пикселях, их жизни, способе их создания, приёмах и уловках в работе с ними. Мы не будем рассуждать о причинах первоначального «спринта», который затем превратился в многолетний марафон, ибо нет ничего более жизненного, чем сама жизнь. Кому нужны причины отсутствия или пауз, если можно просто вернуться к тому, что мы делали, в чём варились, и в чём, даст бог — будем наблюдаться и далее. В пикселях, конечно же!

Сегодняшняя публикация станет очередной, и возможно даже поворотной вехой в нашем повествовании. Наконец-то мы подошли к созданию полноценной анимации персонажей. Двумя предыдущими главами мы охватили анимацию света и тени, а также анимацию неподвижных персонажей (idle-animation) без ярко выраженных действий. Но сегодня наши персонажи пойдут, а в следующей части даже побегут, завоевав то, что уже давно их по праву рождения. Ещё один плодородный регион. И пройдут ещё одну точку, которая ознаменует окончание базового цикла. Наши пиксели наконец-то станут живыми.

В виду большого размера этой части мы разобьем её на два этапа. Пятую и шестую главы «галопа». Всё будет происходить как обычно, с той лишь разницей, что шестую главу вам не придётся ждать ещё год или два. Всё что ей нужно – немного выстояться. Ей стоять, нам копать — за лопаты.

Несколько слов о задачах второстепенных. Во-первых, ещё в первой статье цикла я обещал вам рассказать о создании контента для трёх типов игр. Изометрических (isometric games), платформерах (platform games) и тех, что хорошо видны с высоты птичьего полета (top-down games). Также я обещал вам рассказать о продвинутой анимации света и тени, и о типах передачи полутонов за счёт штриховки (dithering). Каждая из этих тем, не остров и даже не архипелаг. Задачи, по большому счёту, континентального характера. Здесь есть, где развернуться, и есть что копать.

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

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

Как это часто бывает, началом нашей работы станет постановка задачи. Допустим, что мы делаем игру в классическом разрешении для игр древних эпох, 320х200 пикселей. И также предположим, что у нас два цвета на всю графику, и два кадра на любую из анимаций. Задача уже не радует, не правда ли? Что можно сделать в двух кадрах? И даже если это возможно, то… что можно сделать в двух цветах, если один из них фон? Силуэт? Звучит как форменное издевательство. Проверим, так ли это на самом деле.

Начнём с того факта, что у каждого человека есть скелет… частенько даже в шкафу… черт, да иногда их там целые гробницы. Мы создаём нашу анимацию ставя кости в правильное положение в рамках каждого кадра. Но что делать, если скелета и не видно-то толком? Что делать если «вес» персонажа около 70 пикселей? Равный нормальному весу обычного человека в том случае, если мы со свойственной нам фривольностью переведём пиксели в килограммы? Давайте разбираться.

Глава I — Бинарные танцы

Задача поставленная нам нами нетривиальна. Степень погружения в предмет близка не просто к силуэтным рисункам, с которых начался Галоп, где наши первые пиксели сравнивались с наскальными рисунками доисторических людей. Тогда мы начали с CGA-режима и настоящего богатства в виде четырех цветов. Сейчас всё куда интереснее. Мы находимся на самом дне, рядом с низкоуровневым кодом. Ноль и единица. Ложь и правда. Небытие или, наоборот, бытие. Не знаю как вы, а я испытываю легкий трепет. Почти в каждой статье мы, вооружаясь лопатками идём к истокам явлений, стараясь разобраться в самой их сути, и только уяснив для себя некие базисы начинаем движение вверх.

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

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


Глава I. Рис. 1 — Где он ждёт

И давайте нарисуем его в виде сбоку. Потому, что во время движения влево или вправо наш персонаж должен быть виден сбоку. Мы должны представлять, как он выглядит со стороны. Так что… пусть у нашего ожидальщика появится приятель. Или даже целая группа. Правда, с наших съемок мы её затем выгоним. Чтоб не мешали.


Глава I. Рис. 2 — Где он ждёт с приятелями

Даже «12 принципов анимации» аниматоров студии Диснея, Олли Джонстона и Френка Томаса нам в нашей задаче помогут только в одном единственным пункте. Использование компоновок. Приём, когда создаются ключевые кадры, и между ними дорисовываются остальные. Это было бы уместно в случае четырех, шести или восьми кадров анимации. Но у нас-то на горизонте лишь двухкадровая патетика!

Тем не менее, компоновки помогут нам в нашей задаче. Правда для этого нам нужно будет посмотреть другую анимацию. Ту, до которой нам ещё много верст. Чтобы рисовать ключевые кадры – нужно понимать, что это такое. Давайте рассмотрим следующий пример. Главное не пугайтесь, а… не испугавшись, не пытайтесь сразу делать нечто подобное, не освоив азов.


Глава I. Рис. 3 — 24 кадровая анимация сделанная для невышедшего проекта «Drake: The Golden Hind Story», как иллюстрация максимальной нагрузки на кадры, и как следствие на художника.

В этой анимации 24 кадра и надо сказать это было полным безумием. Можно делать анимации ничуть не хуже, с вдвое меньшим количеством кадров. К слову сказать, во множестве современных игр выполненных в стилистике пиксель-арта немного кто замахивается на двадцати четырех кадровую анимацию. Мне же в давно минувшие годы очень хотелось сделать кинематографичный плафтормер (от англ. «cinematic platformer») и я решил побезумствовать. С игрой как-то не сложилось, но анимации остались, и ждали своего часа, чтобы появиться здесь. Хотя бы в виде прикладного материала.

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


Глава I. Рис. 4 — Половина 24 кадровой анимации, как иллюстративный материал для выделения ключевых кадров задним числом. Обычно всё происходит наоборот. Сначала идут ключевые кадры со стороны художника, потом прорисовка промежуточных.

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


Глава I. Рис. 5 — Половина 24 кадровой анимации, переведенный в «белое и черное» как иллюстративный материал для выделения ключевых кадров согласно задаче поставленной в главе. На базе выбранных ключевых кадров и будет создана заданная анимация.

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

Существует две техники создания анимации (согласно «12 принципам анимации») и это – либо использование компоновок, либо прямое фазованное движение. Компоновки это то, чем собираемся заняться мы, создание ключевых кадров и последующая дорисовка между ними необходимых нам дополнительных движений (посредством промежуточных кадров). Прямое фазованное движение это когда персонаж рисуется как есть. Рисуется первый кадр, а затем ему дорисовываются дополнительные кадры по мере его движения (я бы назвал это «анимацией по обстоятельствам»). Это подходит для мультфильма, но не очень подходит для производства графики в играх, где созданная нами анимация сразу уходит в игровой мир в виде персонажа. Исключение могут составить заставки или ролики.

Дело в том, что в случае прямого фазованного движения персонаж может идти куда-то по своим делам, задумчиво почесывая затылок, иногда оглядываясь и возможно даже хихикая над чем-то, и каждый кадр движения, что он будет делать – будет уникальным. Этот приём отлично подойдет для игровых заставок в стиле незабвенных Another World или Flashback. Но в случае если нужно создать несколько кадров анимации, которые при повторе будут работать в цикле (в игровой индустрии в отношении анимации частенько используется не английское слово cycle, а слово loop), и будут исключительно шагом, или бегом – компоновка единственное решение. Таким образом, мы получаем первое, и надеюсь последнее, в сегодняшней публикации определение.

Ключевые кадры – это специфические кадры, который аниматор определяет как ключевые, между которыми затем дорисовываются промежуточные.

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

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

Теперь мы должны определить ключевые кадры в приведенной выше анимации. С целью, определить между какими «ключами» будут дорисовываться остальные кадры анимации, в том случае если бы их не было. Очевидно, что это кадр «максимального раскрытия» когда человек делает полный шаг, и кадр где человек заносит ногу, собираясь сделать шаг или кадр близкий к нему. Потому, что именно эти позиции персонажа в пространстве максимально хорошо описывают шаг. Это намерение сделать шаг (занесённая нога) и собственно сам шаг во всей его красе. Таким образом, если выбрать два кадра из нашего силуэтного списка, то ключевыми кадрами будут первый и шестой кадр, из примера выше.


Глава I. Рис. 6 — Два кадра обозначенных как ключевые. Слева — в цвете. Справа в «черно белом» варианте. На изображении хорошо заметно, что левый вариант выглядит скомканным, тогда как правый вариант при уменьшении и соответствующей чистке может решить поставленную в главе задачу.

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

Теперь вооружившись хотя бы поверхностным знанием о ключевых кадрах, вернёмся к нашим приятелям, а заодно и посмеемся над собой и нашей дилеммой. А именно, анимации двухцветных изображений на два кадра. Так как в нашем случае оба кадра, по определению будут ключевыми. Хотя бы по причине отсутствия других кадров!


Глава I. Рис. 7 — Двухкадровая анимация сделанная с оглядкой на кадры с Рис. 6.

Мы справились с поставленной задачей. У нас есть двухкадровая анимация в диапазоне двух цветов. Однако стоит отметить, что она и стала-то возможной исключительно по причине ограничения цветов. Потому, что любая детализация (цвет, свет или тень) на персонаже, выходящая за рамки силуэта сразу бы расставила всё на свои места, и стало бы ясно, что созданное нами решение не что иное, как иллюзия. Ради забавы я создал семь реплик одного и того же человечка. Не только потому, что с их помощью можно показать, что даже «персонажи на два кадра» могут быть разным в пределах примерно одной весовой категории. Но и вероятно потому, что хотел таким образом сказать спасибо группе «Hanggai» под композицию которой «The Vast Grassland» я несколько часов верстал эту часть Галопа, и которая до сих пор держит меня на плаву.

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


Глава I. Рис. 8 — Эмоциональная зарисовка демонстрирующая разницу между персонажами посредством изменения толщины объектов, смены групп пикселей, изменения силута — для придания персонажем разного характера. Рассматривается как маленький трибьют группе «Hanggai»

Глава II – Триколор

Начнём с того, что речь не идёт о патриотизме. Название главы кратко, но ёмко определило нашу будущую задачу. Три кадра на анимацию шага или любого действия, и… три цвета. Уже богаче, интереснее, но, как и везде – есть свои нюансы. Всегда приятно, когда количество кадров кратное. Два раза занёс ногу, два раза совершил полный шаг, и так далее. Было бы логично использовать четыре кадра, не так ли? Но нам (точнее мне) куда интереснее истязать себя, чтобы добраться до сути явлений. Чтобы понять, как поступать в тех или иных случаях.

Кроме того я вспомнил одну забавную деталь. Именно такое ограничение по количеству кадров на одну анимацию использовал и до сих пор использует движок RPG Maker (в ряде его версий). Мне непонятны резоны таких решений принятых разработчиками (а их было не мало), в силу какой-то диковинной, инопланетной логики. Но мне это подходит как некий вызов, и возможность проиллюстрировать ещё одну иллюзию, которую мы создадим вместе с вами. Прямо сейчас.

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

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


Глава II. Рис. 1 — Разные позы одного и того же персонажа выполненные с целью понять его настроение, и формы. Они не обязательно должны соответствовать тому, что вы сделаете в финале. Нет жестких правил следования. Но всегда есть необходимость подумать перед началом работы, а порой и просто прочувствовать что-либо.

С позами мы определились, с примерным видом ключевых кадров тоже. Но в интересах следствия мы начнём не с одновременного анимирования всего сразу (всех ручек-ножек), но выборочно. И пусть сначала пойдут ноги.


Глава II. Рис. 2 — Иллюстрация прогресса

В случае предыдущего «дуплета» у нас не было никаких цветов, кроме как цвета фона, и цвета, собственно силуэта. Поэтому разбиения на передний и задний план в пределах одного объекта быть не могло. Теперь у нас появился второй цвет, которым мы смогли оттенить задний план, и основным выдвинуть вперед передний план. Именно здесь мы окончательно поймем, что шаг, ровно как и бег, либо любая другая цикличная анимация рождается из повторения одной и той же формы с перекладкой цветов. Используя один и тот же силуэт, в кадре 1-ом и кадре 3-тьем, мы поменяли цвета ног, чем родили иллюзию движения правой и левой ноги. Во втором кадре мы выбрали нейтральную позу, максимально скрывающую ногу в момент её занесения, так чтобы она не сбивала нам общий ритм движения.


Глава II. Рис. 3 — Иллюстрация прогресса

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

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


Глава II. Рис. 4 — Иллюстрация прогресса

Теперь наша левая рука выглядит вполне прилично, и даже чем-то походит на настоящую руку. Ну а правая? Да чёрт с ней. И я не шучу. В ряде случаев некоторыми элементами изображения стоит пожертвовать в угоду плавности движения. Если вы, будучи пытливыми исследователями, изучите спрайты главных героев игр прошлого, то с удивлением увидите, что порой дальняя от наблюдателя рука, либо отсутствует, либо присутствует настолько неявно, что создастся впечатление, что её просто забыли. Но только в том случае, если вы смотрите на кадры по отдельности. В статике. В движении вы этого не замечаете, или замечаете потому, что вам на это указали.

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


Глава II. Рис. 5 — Иллюстрация прогресса

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


Глава II. Рис. 6 — Иллюстрация прогресса

Сдвигом на один пиксель по вертикали в нейтральной зоне мы получаем эффект покачивания, или… подпрыгивания. Выбирайте сами, что вам больше подходит. В случае полного шага человек обычно чуть ниже, в случае стойки с занесённой ногой… выше. Сдвиг всего на один пиксель делает нашу походку более реальной и более живой. Предлагаю на этом не останавливаться. Помните, я упоминал «12 принципов анимации»? Одним из таких принципов является создание выразительной черты в персонаже.


Глава II. Рис. 7 — Иллюстрация прогресса

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


Глава II. Рис. 8 — Иллюстрация прогресса

Точно также как и на четвертом изображении – давайте оттеним причёску персонажа. Мы не будем её анимировать. Просто добавим тени там, где она могла бы отбрасываться волосами. В создании тени мы должны быть аккуратны. Везде важен баланс, и чрезмерная тень может испортить наши результаты. Уникальных схем по созданию таких вот мелких деталей нет. Важна импровизация. Почаще задавайте себе вопрос «а что если?» и не стесняйтесь пробовать что-то новое. В конце концов, стереть десяток неудачных пикселей не так уж и трудно. И коли уж мы начали задавать себе вопросы… а что если мы добавим ещё немного тени на персонаже, чтобы ещё лучше подчеркнуть руку во время движения?


Глава II. Рис. 9 — Иллюстрация прогресса

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


Глава II. Рис. 10 — Иллюстрация прогресса

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


Глава II. Рис. 11 — Иллюстрация прогресса

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

Было бы некрасиво с моей стороны не нанести визит одному старому знакомому. Тот же самый принцип, что мы использовали выше — был использован для одной пост-апокалиптической игры, которая, к сожалению, так и не увидела свет. Спрайты делались именно под RPG Maker, с этим странным ограничением на три кадра в пределах секвенции. Игра не стала реальностью, но зато мы имеем обучающий материал, а значит, что работа уже не была напрасной.
Безусловно, движение персонажа более чем шаг напоминает шарканье, а в некоторых моментах даже русскую плясовую, но, тем не менее, он движется, что также наводит на ещё одну мысль. Работая в ограниченном, или небольшом количестве кадров не стоит бояться больших с точки зрения размера в пикселях, персонажей. Они тоже имеют право на жизнь.


Глава II. Рис. 12 — Персонаж выполненный с параметрами идентичными задаче главы для не вышедшего пост-апокалиптического проекта «Finder». Использовался в демо-версии сделанной на движке RPG Maker.

Тас (о боже, и этот с именем) точно также использует три кадра. Два широких шага, и промежуточный кадр с занесённой ногой. Широкий шаг перерисовывается дважды с перекладкой света и тени. Занесённая нога маскируется, и делается так, чтобы не сбивать общий ритм своим появлением, но поддерживать его. Затем на изображение наносятся характерные детали. К примеру, при ходьбе влево видно седые прядки на его голове, а на одной из рук есть часы. Простое зеркальное изображение уже решило проблему движения влево и вправо.

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

Глава III – Знак четырёх

Нашу третью главу мы также начнём с постановки задачи. Пусть анимация будет иметь четыре кадра. Мы продолжим двигаться в отношении кадров постепенно, по нарастающей. Однако в плане цветов не будем так суровы. Время поста закончилось. Мы уже поняли, что голод и воздержание полезны для понимания сути вещей и отсутствия лишнего веса. Но… как же оргии? Пусть на стол выставят не менее шестнадцати цветов, ибо мы желаем пировать! Условимся также, что если наше обжорство зайдет слишком далеко, мы не будем плакать, соблюдая диетические «тридцать два».

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


Глава III. Рис. 1 — Эмоциональные наброски, как часть поиска образа будущего персонажа. Могут быть выполнены как угодно, в каких угодно видах и стилях. Их задача не сделать набросок в пиксель-арт стиле, но нащупать те эмоции, тот образ, что вам нужен.

Примечание: Касательно данного изображения хотелось бы дать кое-какие пояснения. Обычно я не выкладываю откровенно сырые работы. Но поскольку это мой рабочий скетч, хулиганство и поиск, то его вполне можно приложить к статье. Я считаю, что задачей художника, или того кто им старается быть, или того кто им хочет быть – помочь себе выполнить задачу. Сделать хороший пиксель-арт. А для этого все средства хороши. Как именно вы до себя донесете нужное настроение, и как поймаете образ – ваша личная задача. И больше ничья. Вы можете не публиковать свои рисунки, если стесняетесь, и предоставить наблюдателю, или игроку — окончательный вариант пиксель-арта в виде миниатюры, сцены или игрового ассета.

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

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

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


Глава III. Рис. 2 — Иллюстрация прогресса.

Ровно, как и условились. Пара цветов на лицо, пара на куртку и ещё парочка на штаны. Кепка пока не впечатляет, но не всё же сразу. Кроссовки также разбиты на два цвета в соответствии с концепцией ближнего и дальнего от наблюдателя объектов. Поэтому, не мешкая бежим дальше. Начнём колдовать с тенями. Подчеркнём более темным цветом кепку, сделаем более аккуратной куртку героя (давайте, кстати, тоже дадим ему имя, как и предыдущим парням), и добавим дырочку позади кепки.


Глава III. Рис. 3 — Иллюстрация прогресса.

Теперь давайте снабдим лицо Джошуа дополнительными деталями. Разобьем цвет лица и бороды промежуточным цветом. Так оно станет более привлекательным и объемным. А заодно, как и в самом начале статьи сделаем его ждущим. Не лицо, а персонажа. Вернее его ногу. Ждущую ногу. На это недвусмысленно будет указывать нетерпеливо постукивающий кроссовок. Всего один пиксель и центральный персонаж перестаёт быть мертвым. Пусть развлекает нас, как и всё остальное действо.


Глава III. Рис. 4 — Иллюстрация прогресса.

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


Глава III. Рис. 5 — Иллюстрация прогресса.

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


Глава III. Рис. 6 — Иллюстрация прогресса.

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


Глава III. Рис. 7 — Иллюстрация прогресса.

А теперь займемся магией. Без обращения внимания на конкретные детали будет довольно сложно увидеть различия между предыдущим вариантом и последующим. Но они определенно есть. Одна и та же форма рук оживает за счёт перекладки цветов. Не меняя формы объекта – мы меняем его цвета. Чем ближе объект к наблюдателю, тем он светлее, чем дальше, тем темнее. Это поворотный момент нашей работы. Теперь мы должны провернуть такой же приём с остальными частями тела. Однако, не будем забегать вперёд.


Глава III. Рис. 8 — Иллюстрация прогресса.

Вам не кажется, что у верхнего персонажа идущего на нас кепка выглядит как-то странно? Лично мне она напоминает одну стереотипную кепку для не менее стереотипных персонажей, которые так любят вставлять в дешевых комедиях, чтобы создать третьесортный образ грузина, который уже давно не соответствует реальности (а соответствовал ли вообще)? Давайте-ка исправляться. Добавив на неё света. А заодно, раз уж мы стали работать со Светой, добавим и тени на ноги Джошуа. Чем дальше нога – тем темнее. Обострим цвета в районе теней так, чтобы персонаж стал более объемным в ракурсах, где он идёт на нас, и от нас, в особенности.


Глава III. Рис. 9 — Иллюстрация прогресса.

Коли уж мы начали баловаться с сестричкой Тенью, дадим ей раскрыться во всей красе. Пусть голова как ей и полагается, отбрасывает тень на тело. И пусть куртка снизу также имеет тень, и пусть руки, неряшливо болтающиеся вокруг, также грешат ею. Мы даже воротничок на виде сзади подчеркнём. Хватит одной небольшой линии, а её сдвиг в рамках соседних кадров всего на один пиксель создаст иллюзию двигающегося воротника.


Глава III. Рис. 10 — Иллюстрация прогресса.

Точно также как мы это уже проделывали с руками – возьмёмся за кроссовки. На виде слева и справа просто добавим один пиксель на носке ближнего к наблюдателю кроссовка. Что-то вроде блика. А вот на виде сзади и виде спереди — придётся поработать.


Глава III. Рис. 11 — Иллюстрация прогресса.

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


Глава III. Рис. 12 — Укрупнённый пример анимации за счёт перекладки цветов. На руках форма объекта не меняется, но меняется исключительно цвет, чтобы передать движение объекта в пространстве. На кроссовках используется тот же приём, с незначительными изменениями размера объекта. Хорошо видно, что даже один правильно поставленный пиксель заставялет кроссовок как будто сгибаться.

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


Глава III. Рис. 13 — Иллюстрация прогресса.

Совсем другое дело. Уже не так стыдно как раньше. Тем не менее, лицо у нас щеголяет светом и тенью, передавая информацию об объеме, а куртка выглядит как плоское пятно, пусть и с тенью. Почему бы не добавить света на плечах? Если предположить, что один цвет это основной цвет объекта, а второй цвет – это цвет тени, то почему же нет цвета отвечающего за свет? Давайте исправим это упущение. Не забыв про кепку. Давно уже пора разбить её по цветам, чтобы отделить козырёк от части вертикальной.


Глава III. Рис. 14 — Иллюстрация прогресса.

Теперь мы начинаем скакать как блоха пытаясь «исправить» собственные упущения. Но на самом деле, просто итеративно добавляем на изображение всё новые и новые детали, продолжая работать со светом и тенью. И каждая новая итерация подсказывает нам, где у нас пустоты, где лучше что-то добавить, чтобы персонаж выглядел выигрышно в сравнении с предыдущим результатом. Пришло время добавить тень на футболку, а заодно улучшить штаны снабдив их дополнительной тенью (то есть усилить тень текущую добавив более темные цвета в некоторые фрагменты изображения), которая позволит ещё больше увести ноги в сторону от наблюдателя заставив Джошуа работать бедрами.


Глава III. Рис. 15 — Иллюстрация прогресса.

Как это часто бывает – одно тянет за собой другое. После появления света на объекте становится ясно, что некоторые части персонажа выглядят пустыми. Давайте добавим кокарду почтальона на его кепку. С таким же успехом она могла быть какой-нибудь ещё бляхой, но мы будем считать, что именно так в пиксель-арте и выглядят почтальонские регалии. Не буду скрывать, практически всё, что я делаю, так или иначе связано с пост-апокалиптикой. Назовём это очередным посвящением «Почтальону» Кевина Костнера, к коему я питаю определённую слабость (сколько их было у меня, почтальонов этих!).


Глава III. Рис. 16 — Иллюстрация прогресса.

И чем больше появляется новых деталей, тем явнее просится продолжение работы со светом и тенью. Мне кажется, что куртке на виде сзади и спереди стоит помочь особо. Как обычно. Всего лишь горсткой пикселей. И раз уж мы занялись совсем уж мелочью, полагая близкое окончание пути – давайте добавим ему нашивку на плече. Помните Таса? Проделаем тот же трюк. На одной руке нашивка, а на другой её не будет. Дел-то на два пикселя!


Глава III. Рис. 17 — Иллюстрация прогресса.

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


Глава III. Рис. 18 — Иллюстрация прогресса.

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


Глава III. Рис. 19 — Финальная версия Почтальона.

Нет никакого смысла отпираться и говорить, что творчество «Little Big» с композицией «Skibidi» не имело влияния на последнюю анимацию. Как и все окружающие, я нахожусь под постоянным влиянием таких мощных инструментов как звук и видео. Лет пятнадцать назад я решил, что не хочу иметь ничего общего с такой вещами как телевизор и телевизионное вещание. Однако существует сеть, и YouTube в том числе. Периодически меня накрывает взрывной волной от популярных музыкальных произведений, кинофильмов или телевизионных сериалов.

Глава IV – Необязательный синопсис

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

Компоновки. Метод создания анимации посредством ключевых кадров с дорисовкой между ними кадров промежуточных в количестве необходимом автору.

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

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

Анимация посредством зеркального отражения объекта. Метод создания полноценной анимации на базе половинной анимации, где вторая половина создаётся за счёт зеркального отражения первой половины анимации и при возможном использовании перекладки цветов.

Анимация перекладкой цветов. Анимация, создаваемая за счёт изменения цветов объекта, а не его формы.

Глава V – Эпилог

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

С помощью этих нехитрых уроков и при определённой практике вы сможете создавать графику, которая будет уместно выглядеть в играх класса «Stardew Valley» или «Starbound». Безусловно, данного курса может быть недостаточно, в том случае если вы замахнулись на «Another World» или «Flashback».

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

В ближайшее время планируется выпуск завершающей статьи «Галопа Пикселя», которая ознаменует окончание базового цикла и переход к так называемым DLC. Под DLC я понимаю статьи связанные с пиксель-артом и раскрывающие темы не вошедшие в базовый курс. После стольких лет хочется-таки поставить точку в повествовании. Чтобы хотя бы один из моих писательских проектов последних лет значился завершенным.

В окончании «Эпилога» я бы хотел выразить благодарность своим Патронам с Патреона, моим дорогим ПП, которые поддерживали меня два года. Xочу выразить им свою признательность за долготерпение потому, что скоропостижно поглотившая меня работа в «Dark Crystal Games», и различные проблемы со здоровьем не давали мне заниматься этим делом с должным усердием. И добавлю, что описать словами те эмоции, которые они мне дарят своей поддержкой, а стало быть, эмоции напрямую связанные с выходом новой главы «Галопа» — не получится. Поэтому скажу просто – Спасибо, что вы есть!

Gronkh, Игорь Гриценко, Матей «Retronator» Ян, Калам, Хови Дей (Howie Day), Ben O’Neill. Павел Бартчук, Глеб Рукашников, Александр «Ля-Бестия» Андреев, Росс Вильямс (Ross Williams), Веслом По, Стас Гальюнас, Икс-Раст (xRust), Echo_Memoria, Николай Изодеров, Антон Решетников, Олег, Фернандо Эзра (Fernando Esra), Константин Эпишев, Таня Вексель (Tanya Veksell), LilBrutha

Бункер герр Текста

Заметка первая, классически оправдывающаяся.
Если честно состояние сейчас… наверное так себя чувствует старая струна, которую натягивают, чтобы выдать правильный звук. Два года прошло с момента написания прошлой статьи. Для меня это скорее печальная новость, чем какая-либо ещё. С тех пор как я вступил в должность главного художника, по сути арт-директора пост-апокалиптической игры «Encased» от «Dark Crystal Games» моё свободное время куда-то улетучилось. Справедливости ради надо отметить, что физически — далеко не всё. Я бы даже сказал, что его было достаточно для написания статьи, для создания рисунков, и многих других вещей, которыми я обычно люблю заниматься. Но вот незадача исчезли силы. Совершенно. Этот проект как пиявка высосал из меня всё, что было, и каждый день я словно поднимаюсь на амбразуру дота, до которого ещё километров пятнадцать надо проковылять. И пока ковыляешь – вся жизнь проносится перед глазами. Что самое печальное пятнадцать километров понятие метафорическое. Физически я не покидаю стул квартиры, в которой «снимаю» комнатку.

Заметка вторая, кашевидная.
Самое тяжелое в статье это иллюстрации, их нарезка и верстка. Наверняка все знают, что оптимальное разрешение изображения на Хабре для того, чтобы оно корректно выглядело в статье – 793 пикселя. И это не очень напоминает кратный размер. Поэтому сначала делаются иллюстрации, затем делается кратное увеличение, подбирается нужный размер, в каждом случае разный, а затем создаётся «рамка», которая окружает это изображение. И ладно если это статическое изображение. А что если это анимация, да ещё разделенная изображений на сорок? Такие операции редко, когда можно повесить на скрипт, потому что даже создание срезов иллюстраций – процесс не автоматизированный. Ты должен внимательно отсмотреть материал, поправить огрехи, подумать и т.д. В результате работа растягивается на недели, потому что даже текущий набор изображений нахрапом не взять. Начинаешь лезть на стену. Сейчас, после двойной вычитки статьи я уже нахожусь на грани легкого помешательства. Я даже не уверен, что это статья, и что она вообще может кому-то в чём-либо помочь. Вероятно, такое ощущение создаётся по причине публикации после очередного рабочего дня. Вы уж простите ребята, но в голове у меня форменная каша. И мне известен только один способ проверить статью – доверить её публике.

Инфосфера

Термины, определения и дополнительные информационные ресурсы

Анимация — (от фр. animation — оживление, одушевление) — западное название мультипликации: вид киноискусства и его произведение (мультфильм), а также соответствующая технология. (вики-линк)
12 принципов анимации — набор основных принципов анимации, предложенных аниматорами студии Дисней Олли Джонстоном и Фрэнком Томасом в их совместной работе «Иллюзия жизни: анимация Диснея».
(вики-линк)

Дата последней правки в статье: 25.03.2018 Время: 21:22

  • Идёт рихтовка мелочей. Правка орфографии.
  • Инфо-сфера под вопросом. Голова после рабочего дня абсолютно не варит.

Source: habr1

Метки:





Запись опубликована: 25.03.2019

Поточная конвертация баз Firebird 2.5 в формат ODS12 (Firebird 3.0)

У каждой версии Firebird есть собственная версия формата дисковых структур базы данных – O(n)D(isk)S(tructure). До версии 2.5 включительно, движок Firebird мог работать с ODS предыдущих версий, то есть базы от старых версий открывались новой версией и работали в режиме совместимости, но движок Firebird 3.0 работает только с БД в собственной ODS версии 12.0.

Чтобы перейти на 3.0, базу данных от 2.5 необходимо преобразовывать в новый формат через backup/restore. Разумеется, мы предполагаем, что БД была предварительно подготовлена для конвертации — т.е. метаданные и запросы были проверены на совместимость с Firebird 3.0.

Если следовать стандартному подходу, это означает, что нужно произвести бэкап на версии 2.5, затем установить 3.0 и сделать рестор. Такая процедура приемлема, если есть достаточно времени, но при миграции больших баз данных, или при одновременной миграции нескольких десятков БД, когда время поджимает, можно воспользоваться поточной конвертацией, которая на 30-40% быстрее. Как именно это сделать (под Windows и под Linux), читайте под катом.

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

gbak -b … база25 stdout | gbak -c … stdin база30

Gbak от 2.5 генерирует бэкап в линейном формате и направляет его в stdout, который тут же через stdin подхватывает gbak от 3.0 и создает новую БД.

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

Ниже мы рассматриваем детали для Windows и Linux.

Windows

В случае Windows проще всего сделать полностью автономную сборку Firebird. Для этого берём embed-архив Firebird 2.5, переименовываем fbemded.dll в fbclient.dll, добавляем из архива «обычного» 2.5 утилиты gbak.exe и (необязательно) – isql.exe.

Firebird 3.0 использует единую сборку и не требует никакой доработки.

Самый минимальный вариант (не требующий установки рантайм-библиотек VS2008/VS2010 на целевой системе) содержит следующие файлы:

25/gbak.exe
25/fbclient.dll
25/firebird.conf
25/firebird.log
25/firebird.msg
25/ib_util.dll
25/icudt30.dll
25/icuin30.dll
25/icuuc30.dll
25/Microsoft.VC80.CRT.manifest
25/msvcp80.dll
25/msvcr80.dll
30/fbclient.dll
30/firebird.conf
30/firebird.msg
30/gbak.exe
30/ib_util.dll
30/icudt52.dll
30/icudt52l.dat
30/icuin52.dll
30/icuuc52.dll
30/msvcp100.dll
30/msvcr100.dll
30/intl/fbintl.conf
30/intl/fbintl.dll
30/plugins/engine12.dll

Опытный администратор может заметить, что в 2.5 не включены файлы intl/fbintl.dll и intl/fbintl.conf. Это действительно так, поскольку gbak не использует чарсет коннекта и не конвертирует данные между чарсетами, но на «приемной» стороне Firebird 3.0 эти файлы необходимы при создании индексов.

В firebird.conf Firebird 3.0 рекомендуется добавить:

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

Также, желательно установить и разные значение IpcName для 2.5 и 3.0.

При выборе значений других параметров firebird.conf исходим из простого соображения: на этапе переливки данных в одном процессе gbak работает 2.5, а в другом – 3.0, затем 2.5 завершает работу, а 3.0 начинает построение индексов.

Чтобы ускорить этап построения индексов в 3.0, рекомендуется увеличить размер параметра TempCacheLimit до ~40% RAM (если это выделенный сервер, конечно).

Например, если на сервере 16 Гб RAM, то можно поставить

TempCacheLimit=6G

Разумеется, такое значение можно ставить только у 64битного Firebird 3, поскольку любой 32-битный процесс не сможет аллокировать больше 2х гигабайт памяти.

У 2.5 этот параметр менять не нужно – он и так не может быть больше 2х гигабайт, да и при бэкапе на скорость не влияет.

Перед выполнением операции требуется проверить, что страничный кэш в заголовке базы данных установлен в 0 (команда gstat -h databasename, смотреть строку Page buffers).

Если кэш задан явно в хидере БД, то он переопределяет значения из firebird.conf (и databases.conf в 3.0), и в случае неадекватно больших значений может привести к излишнему потреблению памяти и уходу в своп.

Далее, копируем файлы на целевую систему.

Конвертация проводится после остановки «системной» службы Firebird 2.5, в командной строке с повышением прав до локального администратора (пример):

set ISC_USER=владелец
"25/gbak" -z -b -g -v -st t -y 25.log база25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin база30

В этом примере используется «прямая косая» в кавычках (допустимый «unix-style»), а «шляпка» (символ «^») экранирует символ перевода строки, что удобно при наборе длинных команд. Опция -st(atus) появилась в Firebird 2.5.8 и позволяет записать в протокол данные о времени работы процесса gbak (подробности – в документации).

Linux

На Linux Firebird 3 зависит от библиотеки tommath. В CentOS (RHEL) эта библиотека находится в epel-репозитории, в Ubuntu (Debian) в – системном.

Для CentOS требуется сначала подключить epel-репозиторий и только потом делать

yum install libtommath

Ubuntu не нужно подключать дополнительные репозитории, но в Ubuntu 16 и в Ubuntu 18 устанавливаются разные версии пакетов – libtommath0 и libtommath1, соответственно.

Firebird 3.0 ищет tommath.so.0 и для Ubuntu 18 дополнительно требуется создать ссылку (symlink) c tommath.so.0 на tommath.so.1. Для этого сначала надо найти tommath.so.1.

Искомый путь в Ubuntu – /usr/lib/x86_64-linux-gnu/, но в других Debian-based дистрибутивах может быть иначе.

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

Для Firebird 3.0.2 и выше реализована сборка с –enable-binreloc и отдельная опция установщика (-path путь).

Предполагая, что библиотека tommath и, при необходимости, симлинк для tommath.so.0 добавлены в систему, можно доустановить актуальный (на момент написания этой статьи) дистрибутив Firebird 3.0.4 в, например, /opt/fb3:

./install.sh -path /opt/fb3

После этого можно останавливать системный сервис Firebird и запускать поточную конвертацию.

При остановке Firebird надо учитывать, что процессы Firebid 2.5 в режиме Classic обычно запускает xinetd – поэтому требуется или запретить сервис firebird для xinetd или остановить xinetd полностью.

В firebird.conf для 3.0 на Linux не нужно задавать MaxUnflushed-параметры (они работают только на Windows) и менять настройки Firebird 2.5.

В линуксе локальный (файловый) доступ Firebird 2.5 не эквивалентен embeded-варианту под Windows – сервер 2.5 будет работать в процессе gbak (без сетевой части), но права доступа будут проверяться по базе пользователей, а значит, потребуется не только логин, но и пароль:

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30

После успешной конвертации надо удалить сначала «дополнительный» Firebird 3.0, затем «основной» Firebird 2.5 и уже после этого выполнить чистую установку Firebird 2.5 — причем лучше всего из штатного установщика tar.gz, а не через репозитории, т.к. версия в репозиториях может отставать.

Также, после рестора БД на Linux и переустановки надо проверить, чтобы новая БД имела владельцем пользователя firebird.

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

chown firebird.firebird database

Итог

Кроме экономии времени и места на диске у поточной конвертации есть ещё одно важное преимущество – преобразование базы делается без удаления существующего Firebird 2.5, что заметно упрощает откат при неудачной конвертации (чаще всего — из-за недостатка места или неожиданной перезагрузки во время процесса миграции).

Экономия времени связана с тем, что «классическая» конвертация это «время бэкапа» плюс «время восстановления». Восстановление состоит из двух частей: чтение данных из файла бэкапа и построение индекса.

При поточной конвертации суммарное время получается как «время бэкапа плюс пять-десять процентов» и «время построения индексов».

Конкретные результаты зависят от структуры базы, но в среднем время восстановления примерно равно двойному времени бэкапа. Поэтому, если брать за единицу время бэкапа, то «классическая конвертация» — три единицы времени, поточная — две единицы времени. Дополнительно сократить время помогает увеличение TempCacheLimit.

В целом, поточная конвертация на практике позволяет сэкономить 30-40% процентов от времени поочередного бэкапа и рестора.

Вопросы?

Пожалуйста, все вопросы пишите в комментариях, или направляйте автору методики и соавтору данной статьи — Василию Сидорову, ведущему системному инженеру компании «iBase», по адресу bs at ibase ru.

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

Какой версией Firebird пользуетесь?

Проголосовали 4 пользователя. Воздержавшихся нет.

Теги:

Похожие публикации

Source: habr1

Метки:





Запись опубликована: 24.03.2019

В приватном чате Telegram можно удалять любые сообщения — даже чужие

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

Оригинальный текст сообщения

It’s been 23 years since I first used a private messaging service, and 16 years since I first built my own. The number of electronic private conversations I’ve had over those years is enormous. I am certain this is also the case for you.

Over the last 10-20 years, each of us exchanged millions of messages with thousands of people. Most of those communication logs are stored somewhere in other people’s inboxes, outside of our reach. Relationships start and end, but messaging history with ex-friends and ex-colleagues remains available forever.

It’s getting worse. Within the next few decades, the volume of our private data stored by our chat partners will easily quadruple.

An old message you already forgot about can be taken out of context and used against you decades later. A hasty text you sent to a girlfriend in school can come haunt you in 2030 when you decide to run for mayor. We have to admit: despite all of our progress in encryption and privacy, we have very little actual control of our data. We can’t go back in time and erase things for other people.

Well, we couldn’t. Until today. Today we allowed every user to delete any message in a private conversation from both sides. It doesn’t matter who sent the message and when – you have complete control over it. You can even wipe out the whole conversation from both sides if you want to. No trace will be left on any side.

We know some people may get concerned about the potential misuse of this feature or the permanence of their inboxes. We thought carefully through those issues, but we think the benefit of having control over your digital footprint is more important.

Looking through my Telegram inbox now, there’s not much I would want to delete for both sides. And yet, somehow for the first time in 23 years of private messaging, I feel truly free and in control.
Taking Back Our Right to Privacy
Today, we are giving hundreds of millions of users complete control of any private conversation they have ever had. You can now choose to delete any m…

Страница, на которой анонсируется эта возможность: Taking Back Our Right to Privacy

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

Кроме того, появилась дополнительная возможность сохранить свою приватность в переписке: «анонимизация» отправки сообщений. При включении это опции, сообщения уже не будут содержать ссылку на ваш аккаунт в поле «From», таким образом нельзя будет однозначно связать текст сообщения с вашей личностью.
Активировать ее можно в разделе «Forwarded messages» настроек «Privacy and Security».

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

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

Теги:
Платежная система

Поделиться публикацией

Похожие публикации

Source: habr1

Метки:





Запись опубликована: 24.03.2019

Вся история Linux. Часть II: корпоративные перипетии

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

/ Flickr / David Goehring / / Фото изменено

Зарождение коммерческих продуктов

В прошлый раз мы остановились на компании SUSE, которая в 1992 году первой коммерциализировала ОС на базе Linux. Она начала выпускать продукты для бизнес-клиентов на основе популярного дистрибутива Slackware. Таким образом, компания показала, что опенсорсной разработкой можно заниматься не только for fun, но и for profit.

Одними из первых, кто последовал за этим трендом, стали бизнесмен Боб Янг (Bob Young) и разработчик Марк Юинг (Marc Ewing) из США. В 1993 году Боб создал компанию под названием ACC Corporation и занялся продажей продуктов на базе открытого ПО. Что касается Марка, то в начале 90-х он как раз трудился над новым дистрибутивом Linux. Юинг назвал проект Red Hat Linux в честь красного головного убора, который он постоянно носил во время работы в компьютерной лаборатории Университета Карнеги — Меллона. Бета-версия дистрибутива вышла летом 1994 года на базе ядра Linux 1.1.18.

Следующий релиз Red Hat Linux состоялся в октябре и получил название — Halloween. От первой беты он отличался наличием документации и возможностью выбора между двумя версиями ядра — 1.0.9 и 1.1.54. После этого обновления выходили примерно каждые полгода. Сообщество разработчиков позитивно отреагировало на такой график обновлений и охотно принимало участие в его тестировании.

Разумеется, популярность системы не прошла мимо Боба Янга, который поспешил добавить продукт в свой каталог. Дискеты и диски с ранними версиям Red Hat Linux разлетелись как горячие пирожки. После такого успеха предприниматель решил познакомиться с Марком лично.
Встреча Янга и Юинга вылилась в появление компании Red Hat в 1995 году. Боб был назначен её генеральным директором. Первые годы существования компании были тяжелыми. Чтобы поддерживать предприятие на плаву Бобу приходилось снимать средства с кредитных карт. В какой-то момент общий долг достиг $50 тыс. Однако первый полноценный релиз Red Hat Linux на ядре версии 1.2.8 исправил ситуацию. Прибыль была колоссальной, что позволило Бобу расплатиться с банками.
К слову, именно тогда мир увидел хорошо знакомый логотип с человеком, который в одной руке держит портфель, а другой придерживает свою красную шляпу.
К 1998 году ежегодный объем доходов от продаж дистрибутива Red Hat составлял более $5 млн. На следующий год показатель удвоился, и компания провела IPO при оценке в несколько миллиардов долларов.

Активное развитие корпоративного сегмента

В середине 90-х, когда дистрибутив Red Hat Linux занял свою нишу на рынке, в компании сделали ставку на развитие сервиса. Разработчики представили коммерческую версию ОС, которая включала документацию, дополнительные инструменты и упрощенный процесс установки. А чуть позже, в 1997 году, компания запустила тех. поддержку для клиентов.
В 1998-м вместе с Red Hat развитием корпоративного сегмента Linux уже занимались Oracle, Informix, Netscape и Core. В том же году свой первый шаг в сторону опенсорсных решений сделали в IBM — корпорация представила WebSphere, основанный на веб-сервере Apache с открытым исходным кодом.
Глин Муди (Glyn Moody), автор книг о Linux и Линусе Торвальдсе, считает, что именно в этот момент IBM вступила на путь, который спустя 20 лет привел ее к покупке компании Red Hat за $34 млрд. Так или иначе, с тех пор IBM все больше сближалась с экосистемой Linux и Red Hat в частности. В 1999-м компании объединили усилия для работы над корпоративными системами IBM на базе Red Hat Linux.

Год спустя Red Hat и IBM пришли к новому соглашению — они договорились продвигать и внедрять Linux-решения обеих компаний на предприятиях по всему миру. Соглашение касалось таких продуктов IBM, как DB2, WebSphere Application Server, Lotus Domino и IBM Small Business Pack. В 2000 году IBM начали переводить все свои серверные платформы под Linux. На тот момент уже несколько ресурсоемких проектов компании работали на базе этой операционной системы. Среди них был, например, суперкомпьютер в Университете Нью-Мексико.

Помимо IBM с Red Hat в те годы начали сотрудничать Dell. Во многом благодаря этому в 1999 году компания выпустила первый сервер с предустановленной ОС Linux. В конце 90-х и начале 2000-х Red Hat заключали соглашения и с другими корпорациями — с HP, SAP, Compaq. Все это помогало Red Hat закрепиться в enterprise-сегменте.

Поворотным моментом в истории Red Hat Linux стал 2002–2003 год, когда компания переименовала свой главный продукт в Red Hat Enterprise Linux и полностью отказалась от бесплатного распространения своего дистрибутива. С тех пор она окончательно переориентировалась на корпоративный сегмент и в некотором смысле стала его лидером — сейчас компании принадлежит около трети всего серверного рынка.
Но при всем при этом Red Hat не отвернулись от свободного ПО. Приемником компании в этой сфере стал дистрибутив Fedora, первая версия которого (вышла в 2003 году) основывалась на базе ядра 2.4.22 Red Hat Linux. Сегодня Red Hat всячески поддерживает разработку Fedora и использует наработки команды в своих продуктах.

/ Flickr / Eli Duke /

Начало конкуренции

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

Помимо нее, здесь работали SUSE, TurboLinux, Caldera и другие, которые также пользовались популярностью и «обрастали» верным сообществом. И подобная деятельность не осталась без внимания конкурентов, в частности, Microsoft.

В 1998 году Билл Гейтс делал заявления, пытаясь принизить значимость Linux. Например, он утверждал, что «ему никогда не приходилось слышать от клиентов о такой операционной системе».

Однако в том же году в ежегодном отчете для Комиссии по ценным бумагам и биржам США Microsoft причислил Linux к числу своих конкурентов. Тогда же произошла утечка так называемых Хэллоуинских документов — записок сотрудника Microsoft, в которых анализировали конкурентные риски со стороны Linux и опенсорсного ПО.

В подтверждение всех опасений Microsoft в 1999 году сотни пользователей Linux со всего мира в один день отправились в офисы корпорации. Они намеревались вернуть деньги за предустановленную на их компьютеры систему Windows в рамках международной акции — Windows Refund Day. Так, пользователи выражали свое недовольство монополией ОС от Microsoft на рынке ПК.

Негласный конфликт между ИТ-гигантом и сообществом Linux продолжил нарастать в начале 2000-х. На тот момент Linux занимала больше четверти серверного рынка и последовательно наращивала свою долю. На фоне этих отчетов генеральный директор Microsoft Стив Балмер был вынужден открыто признать Linux главным конкурентом и на серверном рынке. Приблизительно в то же время он назвал открытую ОС «раком» интеллектуальной собственности и фактически выступил против любых разработок с лицензией GPL.

Мы в 1cloud собрали статистику ОС для активных серверов наших клиентов.

Если говорить об отдельных дистрибутивах, то самым популярным среди клиентов 1cloud остается Ubuntu — 45%, за ним идет CentOS (28%) и с небольшим отставанием Debian (26%).

Еще одним фронтом борьбы Microsoft с сообществом разработчиков стал выход ОС Lindows на базе ядра Linux, название которой копировало Windows. В 2001 году Microsoft подал в суд США на компанию-разработчика ОС, требуя изменить название. Та в ответ пыталась признать недействительным право Microsoft на одно из английских слов и производные от него. Спустя два года в этом споре победила корпорация — название LindowsOS было изменено на Linspire. Однако разработчики открытой ОС приняли это решение добровольно, чтобы избежать исков от Microsoft в других странах дистрибьюции своей операционной системы.

А что с ядром Linux?

Несмотря на все противостояния корпораций и резкие высказывания в адрес свободного ПО от ведущих менеджеров крупных компаний, сообщество Linux продолжало развиваться. Разработчики трудились над новыми открытыми дистрибутивами и обновляли ядро. Благодаря распространению интернета делать это становилось все проще. В 1994 году была выпущена версия ядра Linux 1.0.0, а через два года — 2.0. С каждым релизом ОС поддерживала работу на все большем числе процессоров и мейнфреймов.

В середине 90-х уже популярный в среде разработчиков Linux развивался не только как технологический продукт, но и как бренд. В 1995 году прошла первая выставка и конференция Linux Expo, на которой выступили известные в сообществе спикеры, в том числе Марк Юинг. Через несколько лет Expo стало одним из крупнейших мероприятий в мире Linux.

В 1996 году мир впервые увидел эмблему со знаменитым пингвином Таксом, который до сих пор сопровождает Linux-продукты. Его нарисовал программист и дизайнер Ларри Юинг (Larry Ewing) на основе известной истории о «свирепом пингвине», который однажды напал на Линуса Торвальдса и заразил болезнью под названием «пингвинит».

В конце 90-х друг за другом состоялся релиз двух важных в истории Linux продуктов — GNOME и KDE. Благодаря этим инструментам Unix-системы, в том числе Linux, получили удобные кроссплатформенные графические интерфейсы. Выход этих инструментов можно назвать одним из первых шагов в сторону массового рынка. Подробнее об этом этапе истории Linux мы расскажем в следующей части.

В корпоративном блоге 1cloud:

Source: habr1

Метки:





Запись опубликована: 24.03.2019

Программирование LibreOffice Base

  • Tutorial
В opensource офисных пакетах OpenOffice, LibreOffice есть редко используемая и очень скупо документированная возможность — программирование, которая позволяет быстро разрабатывать приложения, аналогичные, например, приложениям Microsoft Access. Сегодня я сделаю небольшой обзор возможностей программирования OpenOffice, LibreOffice.

Вопрос: а зачем?
Я не буду сейчас влазить в исторические причины, т.к. у работников, причастных к автоматизации — это и руководители предприятий, и дистрибьюторы ERP-систем, и IT-службы внутри предприятия, и консалтинг — у всех свои причины (зачастую подкрепленные денежной выгодой) отстаивать именно свою точку зрения. Но я думаю, все согласятся с тем что в повседневной работе подразделений предприятий Excel и его бесплатный аналог Calc (из пакета OpenOffice, LibreOffice) используется очень широко. И уж если такое явление существует, то можно утверждать что это уже не случайность, а так сказать производственная необходимость, и уж точно не вина работников — а скорее недоработка автоматизаторов.

В пакетах OpenOffice, LibreOffice есть компонент для работы с базами данных — Base. Я пытался освоить работу с ним еще до OpenOffice, LibreOffice — во времена StarBase. Но все мои попытки упирались в полное отсутствие документации по разработке (программированию). На сегодня, документации по-прежнему мало, и, наверное, наиболее полезным ресурсом является книга большого энтузиаста программирования OpenOffice, LibreOffice — Andrew Pitonyak, — www.pitonyak.org/book

Поэтому в качестве распространения информации о возможностях программирования OpenOffice, LibreOffice с упором на компонент Base создано это сообщение.

Пакет LibreOffice сейчас актуален в версии 6.2 которую можно получить на сайте разработчика www.libreoffice.org/download/download

Также пакет предустановлен на многих дистрибутивах Linux (иногда не предустановлен пакет Base, так как он сравнительно редко используется).

На этапе создания новой базы данных Base можно выбрать вариант работы со встроенной базой данных или присоединиться к серверу базы данных. То есть многопользовательская работа поддерживается. Для экспериментов можно выбрать любой из вариантов.

Редактор макросов открывается последовательным выбором пунктов меню Tools->Macros->Organize Macros->LibreOffice Basic
Перед вами появится выбор место хранения макросов. Наиболее логичным будет хранить макросы в файле базы данных, т.к. их в этом случае можно будет распространять одним файлом.

Создадим самый простой макрос:

Sub Hello
  MsgBox "Hello"
End Sub

Далее создадим форму Forms->Create Form In Design View. И добавим в конструкторе формы элемент кнопка. После создания кнопки распахнем палитру свойств кнопки, нажав правую кнопку мыши и далее последовательно выбрав Control-Execute Action->Macro->Имя библиотеки->Hello.

Сохранив форму вызываем ее на выполнение и наблюдаем работу макроса. Или не наблюдаем. Все дело в защите которая в связи с участившимися вредоносными макросами отключает их работу по умолчанию.

Больше подробностей, но в настоящее время отчасти устаревших, можно найти в моем заброшенном блоге oobaseinaction.blogspot.com

Если тем вызовет хоть какой-то интерес готов продолжить более конкретными темами.

Теги:

Похожие публикации

Source: habr1

Метки:





Запись опубликована: 24.03.2019

ИТ-гигант представил сервисно-определяемый файрвол

Он найдет применение в дата-центрах и облаке.


/ фото Christiaan Colen CC BY-SA

Что это за технология

Компания VMware представила новый файрвол, который защищает сеть на уровне приложений.
Инфраструктура современных компаний построена на тысячах сервисов, объединенных в общую сеть. Это расширяет вектор потенциальных хакерских атак. Классические брандмауэры способны защитить от атак извне, однако бессильны, если злоумышленник уже проник в сеть.
Специалисты по ИБ из Carbon Black говорят, что в 59% случаев злоумышленники не останавливаются на взломе одного сервера. Они ищут уязвимости в связанных с ним устройствах и «перемещаются» по сети, стремясь получить доступ к большему количеству данных.
Новый брандмауэр использует алгоритмы машинного обучения для определения аномальной активности в сети и в случае опасности сообщает об этом администратору.

Как это работает

Брандмауэр состоит из двух компонентов: платформы NSX и системы обнаружения угроз AppDefense.
Система AppDefense отвечает за построение поведенческой модели всех запущенных в сети приложений. Специальные алгоритмы машинного обучения анализируют работу сервисов и формируют «белый список» выполняемых ими действий. Для его составления также используется информация из базы данных VMware. Она формируется на основе телеметрии, предоставляемой клиентами компании.

Этот список играет роль так называемых адаптивных политик безопасности, на основании которых файрвол определяет аномалии в сети. Система следит за работой приложений и при обнаружении отклонений в их поведении направляет уведомление оператору ЦОД. Для мониторинга активности используются средства VMware vSphere, поэтому новый файрвол не требует установки на каждый хост специализированного ПО.
Что касается NSX Data Center, то это платформа для управления программно-определяемыми сетями в ЦОД. Её задача — связать компоненты межсетевого экрана в единую систему и сократить затраты на его обслуживание. В частности, система позволяет распространить одни и те же политики безопасности на разные облачные среды.
Посмотреть на брандмауэр в деле можно в видеоролике на YouTube-канале VMware.

/ фото USDA PD

Мнения

Решение не привязано к архитектуре и железу целевой системы. Поэтому его можно развертывать на мультиоблачной инфраструктуре. К примеру, представители компании IlliniCloud, предоставляющей облачные сервисы государственным учреждениям, говорят, что система NSX помогает им балансировать нагрузку в сети и выполняет функции файрвола в трех географически удалённых дата-центрах.
Представители IDC говорят, что число компаний, работающих с мультиоблачной инфраструктурой, стабильно увеличивается. Поэтому решения, упрощающие управление и защищающие распределенную инфраструктуру (вроде NSX и построенного на его базе файрвола), будут только набирать популярность у клиентов.
Среди минусов нового брандмауэра эксперты выделяют необходимость развертки программно-определяемых сетей. Такая возможность есть не у всех компаний и дата-центров. Кроме того, пока не известно, как сервисно-определяемый брандмауэр повлияет на производительность сервисов и пропускную способность сетей.
Также компания VMware тестировала свой продукт только против наиболее распространённых типов взломов (например, фишинга). Непонятно, как система сработает в более сложных случаях вроде атаки process injection. При этом новый файрвол пока не может самостоятельно принимать меры для защиты сети — он умеет только посылать уведомления администратору.

Похожие решения

В Palo Alto Networks и Cisco тоже разрабатывают файрволы нового поколения, которые защищают сетевую инфраструктуру по всему периметру. Такой уровень защиты достигается за счет систем глубокого анализа трафика, предотвращения вторжений (IPS) и виртуализации частных сетей (VPN).

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

Второй ИТ-гигант предлагает аппаратные и программные инструменты, которые анализируют и фильтруют трафик на уровне протоколов и функций приложений. В таких инструментах можно настраивать политики безопасности и пользоваться интегрированной базой уязвимостей и угроз для конкретных приложений.

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

О чем мы пишем в Первом блоге о корпоративном IaaS:

И в нашем Telegram-канале:

Source: habr1

Метки: