Деплой из git-а в принципе еще можно как-то понять, ну там деплой-скрипт запускать на push в релиз-ветк, в элементарных случаях это вполне может быть даже git pull.
Но samba на сервер разработки? Откройте для себя realsync того-же Дмитрия Котерова.
На локальной машине — поставил какой-нить убунту, в нее докер.
Написал Dockerfile, в нем явно описываются папки с данными например.
Далее на этой-же машине — собрал образ контейнера.
Написал команду docker-run (или использовал docker-compose например)
Что в результате — полностью повторяемое окружение. Можешь послать другу Dockerfile по почте. Или развернуть на реальном железе — все будет ровно так-же.
Хочется второй контейнер — просто запускаешь, передаешь скажем другие папки.
Вариантов масса, они выглядят сложными, но это только кажется.
В реальности выходит полностью само-документированная конфигурация и легко запускаемые контейнеры с приложением.
Я тоже долго думал-думал, а теперь даже не представляю зачем бы мне хотелось все это руками делать каждый раз.
Обычно используется NAT.
При запуске контейнера указывается какой порт контейнера на какой порт хоста нужно замапить.
Докер — это возможность «упаковать» приложение со всеми потребными библиотеками и обращаться с ним примерно как с единым исполнимым файлом. При том что внутри там может быть много чего.
Это сложно объяснить в двух словах, это другой уровень абстракции. Вместо того чтобы каждый раз париться с установкой чего-то — достаточно сделать правильную «инструкцию» в виде Dockerfile. Далее это приложение может быть собрано в виде контейнера автоматически, отправлено в репозиторий, скачано на другие машины (хоть на миллион), запущено и остановлено как единое целое.
Сам контейнер обеспечивает уровень изоляции наподобии виртуальной машины, но из-за отсутствия слоя виртуализации — падения производительности нет.
Так тут на хабре было очень много уже материалов на эту тему.
Один раз попробовав докер от него уже не отказаться.
Я, к примеру, даже сервер приложений 1С 8.2 и PostgreSQL с патчами 1С разворачиваю docker-контейнерами. Это очень удобно, потому что элементарно повторяемая установка — не нужно все делать вручную, один раз сделал Dockerfile, изоляция приложения — например Postgres-1С требует специфические версии библиотек.
А уже всякие специфические web-приложения, что требуют специфического окружения для запуска — тут докер просто спасение.
Представьте себе что вам нужно N разных версий Web-приложения 1С развернуть, например один боевой вариант и пару новых версий. Или например они выпустят модуль для Apache 2.4? Вам для теста придется разворачивать несколько машин, даже виртуальных.
С докером вы все это сделаете легко и непринужденно. и потом при миграции — опустите один контейнер, запустите другой.
Просто то что вы делаете вручную — это прошлый век :)
Гораздо полезнее оформить это в виде Dockerfile.
Автоматизация процесса развертывания, гарантия повторяемости результата + изоляция приложения от хост-системы.
Докер — это не «вариант виртуализации», это способ «упаковать» приложение и затем автоматически его разворачивать на любом хосте, где установлен докер (а сейчас он работает на любом современном linux-дистрибутиве).
Да причем тут все это? Вы что хотите измерить — эффективность алгоритмов сортировки? Или вашего алгоритма сравнения или обмена?
Ну да, общее время выполнения зависит от операции сравнения и от операции обмена. Но это и есть «операция» в вычислительной сложности алгоритма, именно в этих «операциях» над элементарными объектам она и измеряется. И она не меняется, какими бы они не были.
Ответ в общем виде очевиден — для общей памяти — quicksort, для внешней памяти (когда данные в память одной машины не влезает) — сортировка слиянием (их тоже не один вид кстати).
Есть разные тонкие случаи вроде сортировки целых чисел подсчетом, но это уже хаки.
Каждый кто открывал хотя-бы Вирта ответ этот знает, т.к. алгоритмы сортировки и поиска — одни из простейших.
Конечно жизнь богаче абстрактных алгоритмов, но на то мы и инженеры чтобы применять правильные алгоритмы в нужных местах.
Данная же «работа» не тянет даже на реферат студента-первокурсника. Задача не описана, результаты не соответствуют теории (которая в общем-то не вызывает сомнения, все эти алгоритмы изучены вдоль и поперек, каждый студент их реализует и не по одному разу)
Это все ньюансы реализации, а не самих алгоритмов сортировки.
Когда вы сортируете несколько миллиардов объектов, то причем тут внутренняя сложность этих объектов? Массивы они там или нет — это не важно.
А если есть вопрос сортировки массивов малой длины — то вопрос нужно ставить именно так — и изучать практическую реализацию в реальных условиях. И поверьте — сортировка, реализованная на C++ или на Java или на каком-нить Rust даст вам дико разные результаты — как раз потому что ваши массивы — они не сферические в вакууме а имеют тоже внутреннюю организацию.
Я же вижу в этом посте попытку выбора оптимального алгоритма, при том что не понятно вообще что автор сортирует, какие оптимизации компилятора. Как реализованы алгоритмы — может там ошибки реализации — автор думает что у него QuickSort а на деле нет.
Но очевидно, что если у него нет большой разницы на размерах порядка 10^2-10^3 то причина не в алгоритмах, а в реализации и среде исполнения.
А сами алгоритмы изучены вдоль и поперек, откройте Кнута, том третий :-)
Рекурсия плоха тем что стекфрейм при CALL много больше чем индексов диапазона.
Кроме того — 200 элементов это настолько мало при сегодняшних кэшах процессоров, что и говорить нечего. Все упирается в итоге в какие-нить мелочи, вроде эффективности swap операции.
Сортировки — это один из простейших классов алгоритмов. Они изучены вдоль и поперек. Студенты как первые курсовые работы это делают в профильных вузах — взять десяток алгоритмов, реализовать их, оценить вычислительную сложность, построить график зависимости времени работы каждого алгоритма от размера и степени неупорядоченности массива.
Все еще от языка реализации зависит. Одно дело на ассемблере целые числа сортировать, а другое дело — на Scala списки :-)
Фактически транслятор переводит выражение с языка арифметических выражений в обратную польскую нотацию и тут-же ее вычисляет, потому что это элементарно.
Проблема же в том что вместо изучения теории и ее применения автор потратил время на изобретения очередного велосипеда. И дополнительных знаний не приобрел.
Статей по данному вопросу — вагон и тележка, практически в каждой книге по теории алгоритмов и трансляции разбирают пример как раз на базе вычисления арифметических выражений.
Так что данные карт на этот сайт не попадают, а только статус транзакции передает сбербанк
Но samba на сервер разработки? Откройте для себя realsync того-же Дмитрия Котерова.
На Solaris и FreeBSD это production файловая система.
ZFS не стабильная? ZFS в стадии тестирования?
Ну тогда ext4 вообще экспериментальная
На локальной машине — поставил какой-нить убунту, в нее докер.
Написал Dockerfile, в нем явно описываются папки с данными например.
Далее на этой-же машине — собрал образ контейнера.
Написал команду docker-run (или использовал docker-compose например)
Что в результате — полностью повторяемое окружение. Можешь послать другу Dockerfile по почте. Или развернуть на реальном железе — все будет ровно так-же.
Хочется второй контейнер — просто запускаешь, передаешь скажем другие папки.
Вариантов масса, они выглядят сложными, но это только кажется.
В реальности выходит полностью само-документированная конфигурация и легко запускаемые контейнеры с приложением.
Я тоже долго думал-думал, а теперь даже не представляю зачем бы мне хотелось все это руками делать каждый раз.
При запуске контейнера указывается какой порт контейнера на какой порт хоста нужно замапить.
Докер — это возможность «упаковать» приложение со всеми потребными библиотеками и обращаться с ним примерно как с единым исполнимым файлом. При том что внутри там может быть много чего.
Это сложно объяснить в двух словах, это другой уровень абстракции. Вместо того чтобы каждый раз париться с установкой чего-то — достаточно сделать правильную «инструкцию» в виде Dockerfile. Далее это приложение может быть собрано в виде контейнера автоматически, отправлено в репозиторий, скачано на другие машины (хоть на миллион), запущено и остановлено как единое целое.
Сам контейнер обеспечивает уровень изоляции наподобии виртуальной машины, но из-за отсутствия слоя виртуализации — падения производительности нет.
Один раз попробовав докер от него уже не отказаться.
Я, к примеру, даже сервер приложений 1С 8.2 и PostgreSQL с патчами 1С разворачиваю docker-контейнерами. Это очень удобно, потому что элементарно повторяемая установка — не нужно все делать вручную, один раз сделал Dockerfile, изоляция приложения — например Postgres-1С требует специфические версии библиотек.
А уже всякие специфические web-приложения, что требуют специфического окружения для запуска — тут докер просто спасение.
Представьте себе что вам нужно N разных версий Web-приложения 1С развернуть, например один боевой вариант и пару новых версий. Или например они выпустят модуль для Apache 2.4? Вам для теста придется разворачивать несколько машин, даже виртуальных.
С докером вы все это сделаете легко и непринужденно. и потом при миграции — опустите один контейнер, запустите другой.
Гораздо полезнее оформить это в виде Dockerfile.
Автоматизация процесса развертывания, гарантия повторяемости результата + изоляция приложения от хост-системы.
Докер — это не «вариант виртуализации», это способ «упаковать» приложение и затем автоматически его разворачивать на любом хосте, где установлен докер (а сейчас он работает на любом современном linux-дистрибутиве).
Ну да, общее время выполнения зависит от операции сравнения и от операции обмена. Но это и есть «операция» в вычислительной сложности алгоритма, именно в этих «операциях» над элементарными объектам она и измеряется. И она не меняется, какими бы они не были.
Ответ в общем виде очевиден — для общей памяти — quicksort, для внешней памяти (когда данные в память одной машины не влезает) — сортировка слиянием (их тоже не один вид кстати).
Есть разные тонкие случаи вроде сортировки целых чисел подсчетом, но это уже хаки.
Каждый кто открывал хотя-бы Вирта ответ этот знает, т.к. алгоритмы сортировки и поиска — одни из простейших.
Конечно жизнь богаче абстрактных алгоритмов, но на то мы и инженеры чтобы применять правильные алгоритмы в нужных местах.
Данная же «работа» не тянет даже на реферат студента-первокурсника. Задача не описана, результаты не соответствуют теории (которая в общем-то не вызывает сомнения, все эти алгоритмы изучены вдоль и поперек, каждый студент их реализует и не по одному разу)
Когда вы сортируете несколько миллиардов объектов, то причем тут внутренняя сложность этих объектов? Массивы они там или нет — это не важно.
А если есть вопрос сортировки массивов малой длины — то вопрос нужно ставить именно так — и изучать практическую реализацию в реальных условиях. И поверьте — сортировка, реализованная на C++ или на Java или на каком-нить Rust даст вам дико разные результаты — как раз потому что ваши массивы — они не сферические в вакууме а имеют тоже внутреннюю организацию.
Я же вижу в этом посте попытку выбора оптимального алгоритма, при том что не понятно вообще что автор сортирует, какие оптимизации компилятора. Как реализованы алгоритмы — может там ошибки реализации — автор думает что у него QuickSort а на деле нет.
Но очевидно, что если у него нет большой разницы на размерах порядка 10^2-10^3 то причина не в алгоритмах, а в реализации и среде исполнения.
А сами алгоритмы изучены вдоль и поперек, откройте Кнута, том третий :-)
Кроме того — 200 элементов это настолько мало при сегодняшних кэшах процессоров, что и говорить нечего. Все упирается в итоге в какие-нить мелочи, вроде эффективности swap операции.
Сортировки — это один из простейших классов алгоритмов. Они изучены вдоль и поперек. Студенты как первые курсовые работы это делают в профильных вузах — взять десяток алгоритмов, реализовать их, оценить вычислительную сложность, построить график зависимости времени работы каждого алгоритма от размера и степени неупорядоченности массива.
Все еще от языка реализации зависит. Одно дело на ассемблере целые числа сортировать, а другое дело — на Scala списки :-)
Возьмите миллион элементов, посмотрите что будет.
Кроме того, quicksort без проблем реализуется без рекурсии.
Esc + I открывает в неактивной панели ровно такую-же директорию что и в активной.
И что тут такого Windows-специфичного?
У меня на OSX Midnight Commander, iTerm, Sublime Text а менеджер горячих клавиш встроен в систему.
На Linux аналогично, только iTerm не нужен.
Проблема же в том что вместо изучения теории и ее применения автор потратил время на изобретения очередного велосипеда. И дополнительных знаний не приобрел.
Статей по данному вопросу — вагон и тележка, практически в каждой книге по теории алгоритмов и трансляции разбирают пример как раз на базе вычисления арифметических выражений.