• Локальные политики?

    Keffer
    @Keffer
    ICANN
    gpedit это все политики. А secpol это конкретно политика безопасности и ничего другого.
    Ответ написан
    2 комментария
  • Где есть годные БЕСПЛАТНЫЕ уроки для vue.js?

    @tempick
    На YouTube javascript.ninja - отлично всё объясняет и рассказывает. Но курс там ещё не завершён, если не ошибаюсь
    Ответ написан
    Комментировать
  • Какими навыками должен обладать системный администратор?

    foxmuldercp
    @foxmuldercp
    Системный администратор, программист, фотограф
    Для работы хорошим системным администратором надо:
    нулевой уровень - крепкие нервы и выдержку - часто звонят обычно истерики, у которых "аа, ничего не работает, вы все козлы". Ну или реально, что-то большое и толстое упало и не работает, Вы занимаетесь восстановлением.

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

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

    Учёт и инвентаризация юзерского железа, установленного софта и какие компы за кем числятся, совместно с бухгалтерией.

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

    Прокладка сетей и их диагностика - обрывы, переобжимание патчей, учёт что и куда на патчпанелях воткнуто. что такое вланы и подсети, маски, - это хорошо рассказано в курсах Cisco ICND и более старшем CCNA - маршрутизация и TCP/IP стек

    Ну а дальше - уже всякий серверный стафф - серверное железо, технологии удалённого управления самими серверами (ssh/rdp) и их железом - ipkvm, ipmi, iLO, мониторинг, диагностика.
    Тоже самое с системами хранения данных - дисковые полки, стримеры для бекапов на ленты и библиотеки лент.

    Программная часть серверов - Active Directory и роли Windows Server, какие есть, зачем нужны и как настраиваются, как делается резервное копирование и восстановление данных, как правильно хранить бекапы и где их хранить, как ставится ось - linux, windows, как она правильно настраивается под конкретные задачи - почта, dns, dhcp, брандмауер/фаервол, и т.п., как выпускается в интернет, что такое демилизаризованный сегмент сети.
    Как правильно ставится более сложные сервисы - SQL, почта, веб, мастер установки - 10 минут Next, Next, а грамотное развёртывание - и настройка - вполне нормально от нескольких дней.

    Виртуализация - какая есть, на кой черт нужна.

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

    Побочно - мелкое скриптописание - powershell, bash или крупно-программирование - C#, python, perl, местами веб вроде html/css.

    Вроде ничего не забыл
    Ответ написан
    2 комментария
  • В чём разница между export {name} и export default {name}?

    @camelCaseVlad
    https://developer.mozilla.org/ru/docs/Web/JavaScri...


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

    Касательно экспорта по умолчанию (default), он может быть только один для каждого отдельного модуля (файла). Дефолтный экспорт может представлять собой функцию, класс, объект или что-то другое. Это значение следует рассматривать как "основное", так как его будет проще всего импортировать.

    Ответ написан
    Комментировать
  • Какой компонент редактора с поддержкой форматирования и т.п. лучше использовать для vue?

    Vlad_IT
    @Vlad_IT
    Front-end разработчик
    На VueJS многие плагины портируют, и редакторы не исключение. например CKEditor https://github.com/dangvanthanh/vue-ckeditor2
    Ответ написан
    Комментировать
  • Как в Vue передать из компонента в родителя?

    0xD34F
    @0xD34F Куратор тега Vue.js
    @changeMessage="changeMessage"

    Да ну? Я вот слышал, будто бы

    директивы прослушивания событий v-on внутри DOM-шаблонов автоматически преобразуются в нижний регистр (из-за нечувствительности HTML к регистру), поэтому v-on:myEvent станет v-on:myevent — что делает прослушивание события myEvent невозможным
    Ответ написан
    3 комментария
  • Как сделать табы во VUE JS?

    Fragster
    @Fragster
    помогло? отметь решением!
    Ответ написан
    Комментировать
  • Как быстрее/правильнее загружать данные?

    @Azperin
    Дилетант
    "Сервак стабильностью не отличается" какой смысл говорить о технологии, если у вас сервер любую из них похерит ? Еще и не понятно какие элементы, это товар с хедером и мелким описанием или 400 статей по 60к символов. Если уж юзаешь вью, то возьми любой фрейворк поверх него, типа вьютифая, там есть таблицы с уже встроенной пагинацией.
    Ответ написан
    4 комментария
  • Как быстрее/правильнее загружать данные?

    @AlexndrNovikov
    Solution Architect in Spiral Scout
    Пара кейсов, после которых идея "передать на фронт и фильтровать там" перестает казаться такой хорошей

    1) Прилетел массив на 10 000 элементов. Клиент зашел с Samsung galaxy S2 , попробовал загрузить/фильтрануть, посмотрел, как завис браузер, и ушел. Не забывайте, что не все пользователи сидят с десктопов как у разработчиков с 16-32Gb оперативы. Мобилка может поперхнуться банально из-за большого json-а

    2) Как только потребуется сделать паджинацию - фильтрация на фронте станет выдавать неожиданно некорректные данные

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

    Я верю, что можно сделать выдачу и фильтрацию чисто на фронте с любым количеством элементов, если команда состоит из сплошных ниндзя и рокстаров, но практика в 3 подобные ситуации показывает, что в итоге эту фильтрацию придется переписывать как минимум на гибридную (и поддерживать 2 решения, на фронте для малого количества записей, и на бэке для большого), либо полностью на сервер сайд, так как к сожалению команда никогда не состоит из идеальных разработчиков, чаще из обычных живых людей
    Ответ написан
    2 комментария
  • Создание элемента - какая схема лучше?

    @vintage
    Совсем идеальный вариант: клиент генерирует GUID и для него создаёт свою локальную запись. Далее сразу или по нажатию кнопки "сохранить", происходит синхронизация с сервером. Если на сервере нет записи с таким GUID, то она создаётся. Если есть, то проверяются права доступа и если всё ок, то изменения применяются.

    Чем это хорошо:
    1. Все запросы идемпотентные (их можно безопасно повторять при затыках сети).
    2. Даже у не сохранённой на сервере записи есть уникальный идентификатор, что сильно упрощает клиентскую логику.
    3. Не захламляется база данных временными записями.
    4. Логика работы клиента не зависит от протокола взаимодействия. Вам не нужно предварительно создавать запись, прежде чем её редактировать, не нужно иметь две различные логики работы для записей с локальными идентификаторами и с серверными. Просто создаёте записи и работаете с ними, а взаимодействие с сервером обеспечит отдельный заменяемый адаптер.
    5. GUID можно генерировать сразу человекопонятным. Например, для блога это может быть "vintage/2017-03-08T12:47:33". Обратите внимание, что тут мы не позволяем создавать более одного поста в секунду. Записи, созданные в одну и ту же секунду будут одной и той же записью.
    6. Вы сами решаете когда и как сохранять данные на сервер и это не навязывается вам протоколом.
    7. На запись, которая ещё не сохранена, уже можно дать ссылку. Фактически создана она будет лишь после первого редактирования. Актуально для вики проектов, где вы сначала создаёте ссылку, потом по ней переходите, и только тогда уже заполняете.

    Чем это плохо:
    1. сквозная нумерация не представляется возможной. Но она и редко когда необходима.
    2. Идентификаторы получаются относительно длинными. С другой - они могут содержать некоторую метаинформацию. Например - когда, кем и где создана.
    3. В базе для GUID должна быть дополнительная текстовая колонка с уникальным индексом. Но скорее всего всё-равно у вас такая будет, когда начнёте внедрять [slug](https://ru.wikipedia.org/wiki/Семантический_URL#Slug) для человекопонятности.
    Ответ написан
    1 комментарий
  • Создание элемента - какая схема лучше?

    gzhegow
    @gzhegow
    aka "ОбнимиБизнесмена"
    Попробуй немного изменить представление о программировании. Воспринимай все как "источники данных".

    Есть у тебя база - это источник.
    Есть у тебя пользователь - это тоже источник, НО временный (!).

    Заранее назначать идентификатор нужно только в том случае, если тебе нужно сохранять и потом восстанавливать (навсегда, а не временно). Ты можешь присвоить ID сразу от пользователя, а потом зачем-то делать соответствие база-пользователь через "внешний id" (который ты заранее в программе присвоил) - но пользователь сам не сохраняет свои данные, он отдает их тебе, поэтому ему ID без надобности.

    А вот базе твоей ID - нужен. Потому пользователь заполняет поля, жмет сохранить, а уже потом ты проверяешь - было ли в твоем источнике такая запись по некоторым критериям - например - по символьному коду "Гриша" - "grisha".

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

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

    Чтобы уменьшить такую вероятность, ты:
    а) в идеальном случае рассказываешь ему про ID и даешь выбрать записи из списка, а список - привязывает уже к ID
    б) приводишь введенный им текст по собственному алгоритму - вырезая лишние пробелы, и понимая что в конце получится более менее адекватная строка для сверки - символьный код. Но будь внимателен - алгоритм этот добавляет и другую проблему - введет пользователь два пробела после имени - наверное он ожидал, что это будет другое имя, раз два пробела. И когда он увидит "запись уже есть" - у него возникнет вопрос. Дизайном это нужно обыграть, запретами и тд.

    Таким образом ID - это указатель (!) - как в жизни - указывает "в-туда" - на место хранения записи в конкретной системе. Если ты сделаешь ID в пределах своей программы (пока она запущена) - то в твоей базе тебе придется делать связь "время_запуска_ID_программы_ID_базы" - а это ужас сколько проблем - работа с временными интервалами.

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

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

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

    Вот так где-то.

    ps. https://docs.google.com/spreadsheets/d/1nxHJiDv6dR...
    Ответ написан
    1 комментарий
  • Создание элемента - какая схема лучше?

    @d-stream
    Готовые решения - не подаю, но...
    Как-то на практике чуть удобнее получается нечто типа 2 еще и с объединенным функционалом в виде create or update в "полунеявном" виде.

    То есть если объект не имеет UID, то при сохранении - это явный знак, что он "новый" и надо insert, есть - значит update

    Первый подход - получается двухшаговым, с отсутствием гарантии наличия второго шага. Грубо пользователь захотел создать новую запись - она создалась с дефолтами, а потом пользователь выключил комп...
    В итоге в базе наплодится гора "пустых записей".
    Ответ написан
    Комментировать
  • Как правильно организовать хранение файлов в базе данных MySQL (загрузка и выгрузка через PHP)?

    В коде выдачи случайно нет закрывающего пхп тэга? Вдруг после него лишние пробелы?
    попробуй еще отправлять заголовок header('Content-Length: ' . $size);
    попробуй на всякий случай делать ob_clean перед отдачей, и exit после.

    ну а вообще да, не стоит превращать базу в хранилище файлов.
    Ответ написан
    Комментировать