d'Ivan

Как вести разработку и вести учёт изменений?

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

после шифрования сжимать будет нечего.

update tablename set fieldname = concat('prepend', fieldname) where /**/;

Состояние MySQL-сервера тоже неплохо бы посмотреть (запрос SHOW PROCESSLIST).

Вот и делайте архив, ZIP самый универсальный вариант, в интернете полно информации по работе с архивами с помощью C#.

В MariaDB и Percona реализация стандарта такая же как в MySQL

В фундаментальных вопросах всё тоже самое (приложение менять не придётся), но некоторые отличия всё-таки есть. В основном это улучшения движков, отдельных функций и оптимизация производительности.

Весь список различий: https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql...
Сравнение совместимости: https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql...

FIRST() MERGE и т.п. операторы так же не поддерживаются?

https://mariadb.com/kb/en/mariadb/merge/

В вакансиях иногда пишут знание MariaDB, Percona так в чём там особенность "знания" заключается если это прозрачная замена MySQL - умеешь работать с ней - сможешь и с ними.

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

Может быть, конечно, что их инфраструктура сильно завязана на отдельные фичи MariaDB.
Может быть, это просто отсев тех, кто выпал из прогресса и даже не знает, что это за слово.

Распределить работу покомпонентно.
Любые макеты можно разобрать на следующие компоненты и этапы.

0. Создается общий репозиторий для проекта.
Все работы ведутся сразу в нем. Чем чаще делаются коммиты, тем раньше вылезут и будут исправлены проблемы. У каждого компонента есть свой css/less/sass файл, чтобы легче управлять кодом и избегать merge-конфликтов.

1. Основные строительные блоки:
- Типографика и стили для контента (таблицы, цитаты)
- Элементы форм + стили валидации
- Декоративная графика (иконки, плашки)
- Модульная сетка (сразу респонсив)

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

2. Повторяющиеся компоненты:
- Навигация
- Ленты новостей, событий, блогпостов, результатов поиска, чего угодно
- Типовые формы (логин, регистрация, поиск)
- Табы
- Слайдеры
- и так далее

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

После этих двух этапов у команды готов UI-kit проекта.

3. Предварительная сборка всех шаблонов страниц с реальным контентом

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

4. Редкие кастомные компоненты и модификации

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

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

Обо всем этом говорят Atomic Design, ITCSS и многие другие методологии.

Изучать следует начинать с языка со статической типизаций.

В частости С подходит по этому критерию.
Плюс в изучении С - много литературы и пр. информации.
Минусы - будете не только язык изучать, а еще и со стандартами и их разной кривости реализациями бороться. То, что работает в реализации Clang на Linux не будет работать в реализации MSVC на Windows и в реализации GCC на FreeBSD. Оно вам надо?
Плюс в С легко отстрелить себе ногу.
Плюс реальная польза от Си - это только в слабых микроконтроллерах (мощные модели вполне способны и целые операционные системы запуска), да в написании операционных систем. В других областях или давно перешли или переходят на другие языки.

Я бы предложил Go.

Статическая типизация.
Мощь и простота в одном флаконе.
Жесткий стандарт - разные версии на разных ОС комилируются запросто.

Скриптовые динамические языки - PHP, JavaScript, Python, Ruby, Perl, Lua - плохо для начинающего. Прививает нехорошее отношение к переменным.

Rust, D, Java, Dart - слишком много концепций, не будете знать на чем сосредоточить внимание.

Haskell, Erlang - функциональные концепции, далеко оторванные от массового программирования, которое в большинстве своем императивное.

Полностью покажите текст, судя по ошибке впечатление, что в response и двух байтов нет.

Согласен с evnuh. Вы действительно не разбираетесь в хешировании и шифровании.

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

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

Представьте что нет никакой ложки докера.

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

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

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

Вопрос должен звучать как:
"В чем главное различие между GDI/GDI+, DirectX и OpenGL?"

Windows API - это не только GDI и GDI+, но еще и GUI, файловая система сеть, короче, полноценное низкоуровневое (для XXI века) API ОСи, на котором так или иначе написаны все программы. И вроде это и из названия понятно, не?

GDI/GDI+ изначально предназначены не для игр, а для отрисовки GUI, который в те старо-добрые времена не ассоциировался с такой кучей свистелок и перделок, как сейчас. Потому он и не заточен под сложную графику, и навороты GDI+ это потолок возможностей графики для GUI.

у DirectX так же? Но почему она тогда не является кроссплатформенной?

Ну, хотя бы потому, что скомпилирован в формат dll, который на линуксе, маке, андроиде, айосе - не пойдет. На андроиде еще и архитектуру надо другую. А исходников нет - проприетарный - поэтому не пересобрать.
Дизассемблирование - это незаконно + сложно и тяжело технически, со мной бы такая работа в 6-7-8-значную сумму вылилась (в рублях), и времени заняло месяцы... ))) На эти деньги можно было бы игровой движок какой-никакой сделать, или еще что-нибудь приличное, и продавать его, вместо того, чтобы портировать DirectX "чтобы было".

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

можно, например, медианным фильтром