• Вопрос по Acronis True Image, действительно ли бэкап полный?

    service_man
    @service_man
    Работаю над ServiceSpeedUP.com
    Объем резервной копии зависит о степени сжатия которую вы установили, в некоторых случая он не включает туда временные файлы. Сушествует только один способ проверить работоспособность бэкапа - развернуть его на компьютере. Акронис это одна из лучших программ для бэкапа, но и у нее бывают сбои.
    Ответ написан
    Комментировать
  • Вопрос по Acronis True Image, действительно ли бэкап полный?

    eapeap
    @eapeap
    Сисадмин, Беларусь
    Нужно делать образ диска и MBR - загрузчика. Тогда всё будет ОК.
    Объем образа да, меньше.
    Ответ написан
    9 комментариев
  • Вопрос по Acronis True Image, действительно ли бэкап полный?

    like-a-boss
    @like-a-boss
    Признайся,тебяТянетНаКодМужика,ты—программный гей
    Помнится, когда я делал образы акронисом, размер образа был меньше занятого пространства диска, так что всё норм) Для уверенности повторите процедуру :)
    Ответ написан
    Комментировать
  • Может ли кто-нибудь объяснить суть паттерна проектирования "One True Lookup Table"?

    @AdvanTiSS
    Это не паттерн а антипаттерн. Заключается в том, что новички зачастую используют одну универсальную таблицу для хранения сущностей разных типов.

    Идея: вместо использования трех лукап таблиц
    create table order_status (status_code varchar2(10), status_desc varchar2(40) );
    create table country (country_code varchar2(3), country_name varchar2(30) );
    create table priority (priority_no number(1), priority_desc varchar2(40) );


    Почему бы не использовать одну таблицу в виде
    create table lookup (
    lookup_type varchar2(10), 
    lookup_code varchar2(20), 
    lookup_desc varchar2(100) );

    Подробности тут tonyandrews.blogspot.cz/2004/10/otlt-and-eav-two-b...
    Учите английский, без него туго будет.
    Ответ написан
    Комментировать
  • Для каких задач больше подойдет MySQL а для каких PostgreSQL?

    un1t
    @un1t
    Задачи примерно одинаковые. Для интернет магазина подойдет любая. Обе СУБД проверенны временем и используются в том числе на крупных и highload проектах.
    Для дешевых сайтов лучше MySQL, т.к. есть на любом хостинге. Т.е. если вы пишите коробочную CMS на PHP, то лучше MySQL. Если облачный конструктор сайтов, то без разницы.

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

    У MySQL еще некоторое время назад был самый топорный, читай медленный алгоритм join'ов. В этом плане Postgres был впереди. Ну как впереди, он давал преимущество на коряво написанных приложениях с большим количеством join'ов. Можно ли считать это преимуществом вопрос. Но в последний версиях MySQL 5.6 появились более быстрые виды join'ов. Лично мне это все до лампочи, потому что join'ы во первых были медлеными, а во вторых не масштабируются, поэтому я их не использовал. Да и Django умеет делать быстрый джойн на уровне приложения простым методом ORM - prefetch_related.

    JSONB - технология Postgres, которая позволяет сохранять JSON в таблицу. Я бы не назвал это особым преимущестовм, в MySQL хоранить JSON не проблема, в обычно текстовом поле, только обработку делай на уровне приложения и все. В Джанге, опять же это делается установкой какой-нибудь батарейки django-jsonfield или написанием 15 строчек кода единоразово. Т.е. явно сильного преимущества тут нет, тем более, что такие штуки в любом случае удобнее в Монге хранить.

    Массивы в Postgres. Было бы прикольно, если бы могли не только хранить, но и строить по ним индекс, как в Монге. Но нет, Постгрес предлагает строить по ним полнотекстовые индексы. Ну а если речь идет про полнотекстовый поиск, то на любом большом сайте уже есть поисковый движек, например Sphinx или ElasticSearch, соотвестваенно, я могу масивы и в MySQL серелизовать в строку и индексировать их этим движком.
    Тут преимущество явно на стороне Монги (хотя ее мы тут не рассматриваем), Постргесу еще расти.

    Постгрес умеет строить индексы по XML и видимо JSON. Подумаешь, если какая уже говорил, у нас на проекте есть полнотекстовый движек, то мы можем построить индекс по чему угодно и без Постгреса.

    Полнотекстовый поиск. Вот тут у Postgres действительно есть преимущество как перед MySQL, так и перед MongoDB. Постгрес подерживает русский язык на уровне стемминга, что во многих случаях волне достаточно. Если надо морфологию, то уже поисковые движки надо использовать, а не БД. MySQL не поддерживает языки, а MongoDB поддерживает русский, но не поддерживает оператор AND (блин как это вообще может быть?!).

    Вобщем пока таким явным преимущестовм Постгреса я вижу полнотекстовый поиск, для проектов в которых почему-то нет полноценных полнотекстовых движков. Но с установкой любого движка, это преимущество исчезает.
    Ответ написан
    6 комментариев
  • Для каких задач больше подойдет MySQL а для каких PostgreSQL?

    voidnugget
    @voidnugget
    Программист-прагматик
    Прежде чем холиварить нужно разъяснить 3 вещи
    1. Модель БД в 6ой нормальной форме могут проектировать единицы
    2. Понимать как все эти схемы, каталоги, представления и материализованные представления вписываются в SOA, как производить тестирование, какие функции где хранить, как проставлять тригеры, как подчищать журналы, как разделить представления чтения/записи в рамках CQRS - знают единицы, а использует на практике и того меньше.
    3. PostgreSQL можно сделать быстрее и эффективнее чем MySQL / MongoDB / Oracle, но не наоборот, хотя косячить можно везде :), и там много чёрной магии которая простым смертным просто недоступна. PostgreSQL слишком просто кастомизируется, и этим можно получить просто дикие приросты производительности, особенно если речь идёт о внедрении каких-то кастомных типов данных, индексов и функций агрегации. В остальных решениях "шаг вправо, шаг влево - расстрел". Если вам нужно простое решение которое "лишь бы работало с коробки" - вам точно не стоит использовать PostgreSQL.
    Ответ написан
    1 комментарий
  • Для каких задач больше подойдет MySQL а для каких PostgreSQL?

    SowingSadness
    @SowingSadness
    web-разработчик
    PostgreSQL лучше во всех аспектах, в том числе и по скорости ответа.
    Уже нет причин использовать MySQL.

    PostgreSQL можно продавать со своим продуктом. MySQL - нет.
    PostgreSQL умеет массивы, MySQL - нет.
    PostgreSQL умеет json, MySQL - нет.
    PostgreSQL умеет DateTime с временными зонами, MySQL - нет.
    PostgreSQL умеет работать с временными интервалами, MySQL - нет.
    PostgreSQL умеет нормально работать с unicode, MySQL - нет.
    PostgreSQL умеет DISTINCT по выбранным колонкам, MySQL - нет.
    PostgreSQL умеет ограничивать значения индексов по условиям, MySQL - нет.
    PostgreSQL имеет схемы, MySQL - нет.
    PostgreSQL имеет наследование в таблицах, MySQL - нет.
    PostgreSQL есть нормальная оптимизация JOIN, MySQL - нет.
    PostgreSQL умеет материализованные представления, MySQL - нет.
    PostgreSQL умеет PLSQL, MySQL - нет.
    PostgreSQL умеет Python функции, MySQL - нет.
    PostgreSQL умеет ключи из внешних источников, MySQL - нет.
    PostgreSQL умеет нормальные(вложенные) транзакции, MySQL - нет.
    MySQL есть проблемы с установкой и удалением своих сервисов под Windows, PostgreSQL - нет.
    ̶P̶o̶s̶t̶g̶r̶e̶S̶Q̶L̶ ̶у̶м̶е̶е̶т ̶а̶с̶и̶н̶х̶р̶о̶н̶н̶у̶ю р̶е̶п̶л̶и̶к̶а̶ц̶и̶ю̶, ̶M̶y̶S̶Q̶L̶ ̶-̶ ̶н̶е̶т.
    Ответ написан
  • Почему Магенто пишет "категории нет в наличии"?

    Сообщение на витрине «категории нет в наличии» означает, что у текущего магазина (отображаемого на витрине) многомагазинной системы Magento отсутствуют товарные разделы.
    Из того, что в административной части есть какие-то товарные разделы, не следует, что эти товарные разделы привязаны к текущему магазину.
    Чтобы привязать товарные разделы к конкретному магазину, надо обязательно сделать их подразделами корневого раздела данного магазина.
    Корневой раздел, в свою очередь, должен быть привязан к данному магазину в административном разделе управления магазинами (в Российской сборке Magento это делается в разделе «Система» → «Магазины»).
    Ответ написан
    Комментировать
  • Как вникнуть в тонкости back end разработки?

    Stac
    @Stac
    Серверные скрипты в своем простейшем случае (PHP, Perl, CGI-скрипты на любых других языках) весьма похожи на неинтерактивные консольные программы (утилиты командной строки).

    Они принимают данные на вход через заголовки и тело HTTP-запроса, что-то быстро делают и выводят результат [в браузер].

    PHP или CGI-скрипт вызывается вебсервером (программой) в процессе отбработки входящего запроса (request) . Он же получает результат работы скрипта и фактичеки возвращает браузеру в ответном HTTP-запросе (response).

    HTTP-запросы это чистый текст с минимальной структурой, с которой имеет смысл ознакомиться.

    В некоторых технологических стеках сама прикладная программа и является вебсервером (например, node.js и Ruby On Rails - впрочем, не влададею эти технологиями, могу ошибаться).
    Но даже в этом случае прикладной программист не работает пакетами и битами (может, если захочет, но на практике это не нужно).

    Прикладная среда выполнения (вебсервер или фреймфорк), приняв запрос, дает программисту доступ к его элементам через глобальные переменные или объекты, в зависимости от того, как принято в конкретном языке программирования.
    Для PHP это глобальные переменные (ассоциативные массивы) $_SERVER, $_REQUEST и др. В первой можно найти некоторые HTTP-заголовки, кое-какие данные о сервере и удаленном клиенте (IP адрес, например). Во второй собраны все входные данные, переданные через URL (site.ru/page.php?key=value&key2=value2), в теле POST запроса, через куки (фактически HTTP-заголовки специального формата) и переменные окружения [операционной системы].

    Различные фреймворки могут иметь классы и объекты с именами типа Request.

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

    Если данных очень много и их не просто надо читать, но для начала найти какие-то фрагменты (конкретные строки таблицы, поля объекта) по каким-то критериям, а потом, возможно, как-то обработать, то можно использовать СУБД.

    СУБД бывают встроенные и клиент-серврные.
    Пример встроенной это SQLITE, которая встроена в PHP как модуль расширения. Она также используется в iOS, Android, браузерах Firefox, Chrome и многих-многих других программах.

    Клиент-серверные чаще всего это MySQL (даже чаще чем надо), PostreSQL, MS SQL Server, Mongo DB, есть куча других.

    Серверная часть такой СУБД работает как отдельный сервер (программа), возможно на отдельном сервере (компьютере). Клиентская часть это модуль в среде исполнения (расшириние PHP, библиотека функций) или может условно отсутствовать, если СУБД имеет HTTP API. В этом случае клиентскую часть пишет прикладной программист на своем языке.

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

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

    Все операции на сервере происходят по необходимости, мы открываем соединение с БД по необходимости, принимаем запрос по необходимости, говорим что переменая имеет тип int unsigned исходя из необходимости.


    Нет какой-то абстрактной необходимости. Первопричина всего (на прикладном уровне) - входящий запрос. Вебсервер ожидает постоянно входящие запросы (слушает TCP-порт).
    Вот запрос пришел. Сервер согласно своим настройкам определяет, может ли он сам его обработать (например, "отдать статику") или он должен передать запрос другому обработчику по цепочке. Таким обработчиком может быть, например, PHP.
    Вебсервер запускает интерпретатор PHP и передает запрос ему.
    PHP определяет (в общем, по ссылке, которая есть в параметрах запроса), какой PHP-скрипт надо выполнить, ищет его и выполняет. Результат работы скрипта - HTTP-response (фактичеки это plain text, содержащий служебные заголовки, в т.ч. куки и тело с HTML / XML / JSON, etc. ) - отдается обратно вебсерверу, он возвращает его туда, откуда пришел запрос (на IP адрес и порт), часто в браузер.

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

    Мы, прикладные программисты, не опускаемся ниже HTTP-протокола. А используя фреймворки, даже HTTP можем не касаться, хотя знать и понимать его надо.
    Т.е. до всех этих TCP-портов и настроек сервера нам, как праивило, дела нет (пока все работает).
    Первое - удел скорее системных программистов, второе - сисадминов или модных ныне девопсов.

    Что почитать, чтобы лучше понять операции на бэке, которые не поймешь сразу ...


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

    Сейчас PHP все еще самый простой путь в back-end разработку. А раз вы упоминаете про int unsigned, то вам будет привычен и его Си-подобный синтаксис. Типа данных такого, однако, в PHP нет.
    Ответ написан
    2 комментария
  • (Yii2) Как сохранить сразу несколько строк в базу?

    @hector
    php программист
    Если не использовать AR, то batchInsert()
    Ответ написан
    Комментировать
  • СЕО. Не будет ли хуже от таких ссылок?

    @Los_Pochtovyi
    Смотря под что оптимизируем. По опыту - гуглу на формат ссылок по большому счету плевать, а вот яндекс исторически предпочитает ссылки:
    а) с расширением (в большинстве CMS легко настраивается);
    б) осмысленные (это и гугла касается).

    То есть примерно такого вида: pasport-stanok-xxx.html (где xxx - общепринятое название/артикул модели на случай, если такой станок искать вообще будут). При таком названии страницы велик шанс что при поиске типа "паспорт станка <модель>" ваш сайт вывалится одним из первых.

    Но тут есть вопрос - а надо ли вам оптимизировать под точки входа эти карточки? Возможно, логичней заоптимизировать точки входа по производителям или по какому-то иному принципу (надо смотреть, что народ ищет).
    Ответ написан
    Комментировать
  • При загрузке Windows XP вылазиет cmd-окно "Не удается найти указанный файл". Как избавиться?

    zmeyjr
    @zmeyjr
    Дисклеймер в профиле.
    смотрим тут www.microsoft.com/resources/documentation/windows/...

    Executing registry subkeys
    If you do not specify /d in string, Cmd.exe looks for the following registry subkeys:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun\REG_SZ
    HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun REG_EXPAND_SZ
    If either one or both registry subkeys are present, they are executed before all other variables.
    Caution

    Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

    Enabling and disabling command extensions
    Command extensions are enabled by default in Windows XP. You can disable them for a particular process by using /e:off. You can enable or disable extensions for all cmd command-line options on a computer or user session by setting the following REG_DWORD values:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\EnableExtensions\REG_DWORD
    HKEY_CURRENT_USER\Software\Microsoft\Command Processor\EnableExtensions\REG_DWORD
    Ответ написан
    Комментировать
  • Есть ли инструменты обновления браузера на события изменения файлов (html, php, js, etc)?

    Hereigo
    @Hereigo
    Пишу на C# + Asp.Net (MVC) + .Net Core
    Есть дополнение к Mozilla Firefox.
    Указываешь в настройках папки и/или файлы, на изменения которых реагировать и автоматически обновлять страничку.
    И редактируй файлы, чем угодно!
    https://addons.mozilla.org/ru/firefox/addon/auto-r...
    Ответ написан
    2 комментария
  • Есть ли инструменты обновления браузера на события изменения файлов (html, php, js, etc)?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    https://www.npmjs.org/package/gulp-webserver - рекомендую. Так же webstorm/phpstorm имеют на борту плагин LiveEdit. Это если вы хотите обойтись без node.js
    Ответ написан
    5 комментариев
  • Есть ли инструменты обновления браузера на события изменения файлов (html, php, js, etc)?

    AMar4enko
    @AMar4enko
    Во всех более-менее известных инструментах для фронтенд-разработки давным-давно есть livereload плагины.
    https://github.com/gruntjs/grunt-contrib-watch#opt...
    https://www.npmjs.org/package/gulp-connect

    Изучайте инструментарий, сейчас без этого никуда даже верстакам.
    Ответ написан
    Комментировать
  • Действительно ли back-end разработка более консервативна, чем front-end?

    hrls
    @hrls
    Половина ответа в вопросе, но дьявол в мелочах.
    Действительно, для относительно продуктивной backend-разработки практически на любом языке программирования необходимо знать несколько базовых фреймворков и тулов, которые решают большинство задач. Это скелет ~90% приложений сложнее hello world. Хотя и этот скелет меняется и развивается, пусть и не так быстро как хотелось бы, как разнообразные отростки (не консервативность, но более долгий жизненный цикл). Суммарный вес технологий и инструментов не меньше, и уж точно не менее динамично изменяющийся, чем у frontend-разработчиков.
    Далее личный опыт на примере Java.
    Лет 7-8 тому достаточно было знать Spring, Struts, Hibernate да Apache Commons в довесок для разработки большинства решений. Ну и J2EE-стек для задач Enterprise-уровня.
    В году 2014 Spring, Hibernate все также в арсенале программиста, но появилась куча абсолютно новых вещей вроде AMPQ, Hadoop, Netty, Scala с функциональной парадигмой, мультиязычные окружения с Clojure/Groovy/JRuby; стали чаще встречаться альтернативные реализации популярных библиотек (например Guice / Guava); старые технологии вроде J2EE стали использоваться несколько реже. А одних только Key-Value хранилищ, кэшей и прочих NoSQL как грязи. Изменился даже сам подход к построению приложений – мало кто в 2005 слышал про asynchronous event-driven модели и отталкивался при проектировании от REST-стиля (собственно, там и корни frontend-девелопера как отдельной специализации). Про эволюцию систем сборок, VCS, бенчмарков и прочих "микро"-элементов можно расписывать не одну простыню.
    И да простят меня frontend-товарищи за, возможно, чванливый тон, но раскурить тонкости работы async IO в зависимости от ОС-специфики вроде epoll/kqueue или учитывать CAP-теорему при построении middleware-кэша это уровнем сложности повыше, чем новый CSS-препроцессор и CoffeeScript c очередным MVC / MVVM-фреймворком. Некоторые задачи, вроде синхронизации потоков, так и вообще лежат большей частью в области математики.
    Уверен, что и в frontend-разработке существуют задачи сложнее и интереснее поехавшей на пиксель верстки и обновления полей после парсинга JSON, но ИМХО backend-разработка ближе к системному программированию старой школы, в то время как frontend суть прикладное программирование с примесями дизайна.
    Frontend-инструментов больше, backend-инструменты сложнее.
    Ответ написан
    4 комментария