- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Стоимость сайтов на ВП упала ниже плинтуса
Абстрактная фраза же.
Нет, понятно, если заниматься конвеерным изготовлением стаеллитов или типа того - наверное упала, я не знаю :)
Сложный инстанс никогда не будет дешёвым.
Хоть на WP, хоть на инклюдах, хоть самопис на чудо-фреймворке.
В конечном итоге, платформа сама по себе уходит на задний план, а в оценке главенствующую роль приобретает вся система (вместе со структурой, контентом, дружественностью к посетителю, конечному администрирующему пользователю, SE).
Хорошо, убедили, отличная штука ФФ системы. А что можно реализовать на них еще, кроме новостника? Например магазин со сложным составным товаром? Это будет практичнее чем использовать БД?
В ИМ есть только одна серьезная проблема - поиск.
Если база товаров велика(скажем послать её всю клиенту, либо держать в ОЗУ будет слишком "дорого"), И, если требуется поиск по множеству полей, то, вероятно эту функцию придется реализовывать через БД.
И как правило, в результате, даже небольшой ддос и "мало не покажется".
Для всего остального никаких БД вроде как не нужно... ну т.е. можно придумать какие-то вещи, для которых она может пригодится, но обычно, 99% их лучше-бы не в ИМ было, а где-то снаружи и от него отдельно.
Всё со словом sql - это удешевление процесса разработки, а не улучшение результата.
ЗЫ. Вот что реально нужно - это какой-то модуль-демон для нгикса для обслуживания некоторых "запросов".
Потому как каждый раз диск дергать не всегда разумно, он конечно кешируется, но порой хочется чуть больше над этим контроля.
Абстрактная фраза же.
Нет, понятно, если заниматься конвеерным изготовлением стаеллитов или типа того - наверное упала, я не знаю
В целом да, абстрактно. Но. Меня звали в прошлом году в одну компанию, пилить на вордпрессе, я им выкатил цифру - задумались. Через 3 месяца эта же компания взяла меня на питон за эти же деньги и еще и подгоняли - выходи поскорее)
---------- Добавлено 09.01.2020 в 16:28 ----------
Всё со словом sql - это удешевление процесса разработки, а не улучшение результата.
Очень смелое заявление))) Очень сомневаюсь, что наша система онлайн обучения на файлах бы стала сильно лучше)
Но всё равно мне кажется что в стандартных случаях использование БД не сильно удорожает проект если изначально не жлобиться на ресурсы/администрирование.
Дело не в ресурсах, БД отвечать может по минуте при том при 0 нагрузке на железо сервера. С БД надо уметь работать, она умеет делать круто связи (говорим за классическую реляционную БД), но связи нужны не везде, для того чтобы отрендерить текст страницы с метатегами можно даже не ставить БД которой как принято отдают 80% ресурсов сервера. Причин на самом деле может быть много, да БД это удобно, но не обязательно, когда можно без неё, то зачем она? Например давайте так, как бы вы переносили изменения в БД с одного сервера на другой (с дев сервера на продакшен)? У фф цмс своя ниша, БД тоже работает на файлах, разница лишь в том, что перед этими файлами есть сервер, который умеет делать некие манипуляции.
---------- Добавлено 09.01.2020 в 17:57 ----------
* Проще = понятнее и логичнее
* Удобнее
* Нативное приложение на всех поддерживаемых платформах (привет GitBashу)
* Гуевый клиент (TortoiseHG) - полноценный клиент, делающий все и ничего не прячущий, в отличие от обсоска TortoiseGit (а нормального клиента надо долго и упорно искать)
С гитом знаком каждый мидл, чего не скажу за другие системы. Достаточно? =)
PS. Проще и удобнее никак не сочетается с гуевым клиентов =)
---------- Добавлено 09.01.2020 в 17:59 ----------
В ИМ есть только одна серьезная проблема - поиск.
Если база товаров велика(скажем послать её всю клиенту, либо держать в ОЗУ будет слишком "дорого"), И, если требуется поиск по множеству полей, то, вероятно эту функцию придется реализовывать через БД.
И как правило, в результате, даже небольшой ддос и "мало не покажется".
Поиск не проблема фф цмс, поиск в реляционной БД это тоже проблема, если нужен нормальный поиск, то юзают как например эластик, и его вполне можно юзать вместе с фф цмс.
---------- Добавлено 09.01.2020 в 18:02 ----------
У БД множество преимуществ, например транзакции в коробке, хранимки и так далее, но если можно без неё (БД), то зачем её ставить?
С гитом знаком каждый мидл, чего не скажу за другие системы. Достаточно? =)
Нет. Потому что по факту гитбоем является любой джун-"прогер", и что? Узость кругозора называем точкой зрения
Проще и удобнее никак не сочетается с гуевым клиентов
Как раз сочетается... В некоторых частностях (могу рассказать, но ведь не надо?!), но да - можно спокойно жить только в консоли или в IDE (если есть поддержка меркуриальская в нем, что редкость)
или в IDE (если есть поддержка меркуриальская в нем, что редкость
Вот уж не думал, что обычная вещь, и редкость.
Возьмём фришный NetBeans. Git, Mercurial, Subversion из коробки.
Возьмём фришный NetBeans.
А рядом будет длинный список тех, кто не умеет, ни из коробки, при плагинами/расширениями. Ну и я просто не стал говорить, что SCM нужен не только кодерам, а у них немножко другие инструменты, где тоже сильно чаще (по понятной причине) only Git
Да оно нафиг в GUI не нужно.
Из консоли всё делается.
К слову...
Меркуриал проще, но его адепты получается прям божества! Гит сложнее - но сразу получаешь презрительное - гитбой( что за хрень?)
Тот же Пайчарм подерживает хоть ртуть хоть гит с очень удобным интерфейсом, кучей плагинов при необходимости - в чем проблема? Не нужно ставить еще черепашку и прыгать туда-сюда.
Вообще не понимаю холивара