All streams
Search
Write a publication
Pull to refresh
-8
0
Send message
if (savedTokens != null)
Используйте лучше строгое сравнение и вот почему — dorey.github.io/JavaScript-Equality-Table

data.input == 'true' ? 'checked' : ''
Здесь ошибка(сравниваете булево со строкой), проще сделать так
data.input ? 'checked' : ''

Так же Вы выбрали не очень удобную структуру данных для хранения данных задач(строки), лучше было бы использовать массив объектов и использовать всего один ключ в localStorage, вообще без возни с генерацией токенов(ID?):
localStorage.setItem(`tasks`, JSON.stringify([ {a:1,b:2},{a:2, b:4}]));
JSON.parse(localStorage.getItem(`tasks`));
console.log(...JSON.parse(localStorage.getItem(`tasks`)));
// {a: 1, b: 2} {a: 2, b: 4}


Кстати вот несколько идей, как можно улучшить ваш todo-list: добавить возможность удалять задачи(крестик справа от задачи например), добавить инпут слева от кнопки New Task и генерировать текст новой задачи из данных в нем (сбрасывать ввод после добавления задачи), по чекбоксу слева от задачи зачеркивать текст задачи (статус выполнено), добавить в шапке количество задач (общее, выполнено, не выполнено), добавить возможность указывать срок выполнения задачи (опционально, например дату и время к которой задача должна быть выполнена) и подсвечивать не выполненные в срок задачи красным цветом.

Удачи в изучении Javascript!
Я не против WP, сам на нём более 10 лет делаю проекты, но для каждой задачи — свой инструмент.
Согласен. Только это не повод становиться рабом лампы. Преждевременная оптимизация только ради оптимизации и в ущерб удобству.

Скажите, почему все проекты в мире не делаются на Wordpress? Он хорош для новичков, когда неохота разбираться. Но на выходе, с чем стакливался достаточно часто, он даёт очень тяжелые сайты, которые трудно оптимизировать в силу того, что кодовая база WP тянется с 2003 года.
Wordpress по статистике — самая популярная CMS. И в целом сам факт того, что из версии к версии используются API и решения из самых первых версий, доказывает что изначально был использован правильный подход к архитектуре WP. И WP — полноценная CMS, в отличие от сборщиков и генераторов, соответсвенно и спектр задач отличается. Так вот для задачи по ведению небольшого блога любая CMS подойдет лучше любого генератора. Задачи оптимизации (в т.ч. поисковой) — это задачи на вырост и они тоже решаемы, это не повод изначально выбирать неудобный инструмент.

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

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

Насколько я вижу у генераторов могут быть 2 узкоспециализированные задачи:
1) Публикация в html из другого формата большого обьема документов (например документация к проекту пишется в md разработчиками, а для пользователей автоматически генерируется в html)
2) Очень жесткий хайлоад, если вообще возможно перевести сайт на статику. В любом случае такую задачу нужно решать комплексно(балансировка, кеширование, тюнинг nginx и т.д.) и генератор тут поможет только с подготовкой контента из другого формата(если это вообще будет необходимо).

P.S.: Я посмотрел документацию проекта и стало понятно откуда вообще это упоминание про блоги — Вы просто перевели как есть.
Подскажите кейс использования подобных генераторов в продакшене, или не проще настроить Webpack для конкретной задачи (конвертации md в html например), без лишних инструментов и необходимости их изучать? Ведь по большому счету это универсальный сборщик из «чего-то-там» в HTML, который собирает все это хозяйство по команде?
Как движок блога использовать подобное станет только садомазохист или гик — почему не использовать любую популярную CMS? Да, нужна база, да, возможно придется иногда обновляться — зато это решение в 1000 раз более гибкое, проще и дешевле в поддержке.
С CMS вам не придется искать дорогого программиста на Vue.js или React, чтобы встроить функционал интернет-магазина в ваш блог, или обучать какую нибудь девочку контент-менеджера как через вот этот вот богомерзкий *.md написать новый пост (а еще картинки надо по ftp залить в нужную директорию и не забыть их имя вставить в документ!).
С другой стороны если у вас не такой большой блог и вы ведете его сами для себя, то что вы получите от этих плюсов со скоростью работы статичного HTML, насколько вообще критично использовать подобные велосипеды генераторы?
Большое спасибо за статью, вы здесь поделились своим опытом, но во что не понятно — как этот опыт может быть полезен другим компаниям? Большинство подобных статей можно подвести под общий заголовок «как мы в большой компании Х внедрили процесс Y». Т.е. я говорю о том что в компаниях, которые созрели для процесса Y, он скорее всего уже внедряется по своему уникальному сценарию, а в компаниях которые не созрели для этого — он не нужен и может даже мешать бизнесу.
На сайте Сибирикс и «Спасской башни» не отображаются состояния фокуса на ссылках (по нажатию TAB). Могли бы написать похожую статью про «грешки» верстальщиков? Было бы интересно почитать.
Что такое staging и рефакторинг? Фронтир, бэк-офис? Я как админ среднего пошиба (в подчинении около 80 серверов) не знаком с данными терминами и не понял совершенно о чём речь. Если целью статьи является мотивация к изучению систем конфигураций и объяснение для чего они нужны, то вы не мотивировали и не научили ничему меня. Ощущение что написано для тех кто уже в теме или созрел. Можете привести какие то конкретные примеры чем мне, как администратору, данные системы помогут в работе и какие процессы помогут автоматизировать?
Использую oxidized для этих целей и сохраняю на приватный gitlab — всегда можно посмотреть историю изменений. Работает и с Cisco, и с Mikrotik и еще бог знает с чем.
github.com/ytti/oxidized

А не проще добавить небольшой диск под boot изначально, раз речь об виртуальных серверах и теоретически возникнет проблема с последующим расширением раздела(хотя опять же в таком случае проще добавить диск в vg расширении имхо)?
А root уже можно монтировать в lvm:
<img src=«А не проще добавить небольшой диск под boot изначально, раз речь об виртуальных серверах и теоретически возникнет проблема с последующим расширением раздела(хотя опять же в таком случае проще добавить диск в vg расширении имхо)? А root уже можно монтировать в lvm:

Аналог можно передать и по витухе, главное правильно обжать патч-корды. Кабель закладывается на моменте проектирования, не всегда есть возможность что-то переделать и это понятно. Проектировал и внедрял с командой гостиницу с нуля на 100 номеров (Серверная+АТС+Видеонаблюдение+Wi-Fi+СКС ~700 портов) и в части телефонии остановились на том, что аналоги в гостевых номерах на порядок дешевле в стоимости (кстати в ванной параллельный телефон, т.е. получилось минимум по 2 телефона на номер). Опять же если аналог откажет — заменить его может даже горничная, в отличие от SIP, который нужно хотя бы предварительно сконфигурить для замены. Использовали решение от Unify(бывший Siemens), а не Asterisk.
Неужели кто то пользуется розеткой Ethernet в гостинице, когда есть Wi-Fi?
От аналоговых телефонов было решено отказаться еще на стадии обсуждения.

Почему? Был ли экономический расчет или это чисто идеологическое решение? По моему чисто на аналоговых аппаратах в гостевых номерах можно сэкономить 50-70% (раз уж руководство упиралось в экономию), да и не нужен там функционал цифрового телефона.
2

Information

Rating
Does not participate
Registered
Activity