Информация о пользователе

Ник: Kirill
Страна: Украина
Статус: Активен
С нами с:
06.02.2017 21:27
Лайки
Лайки: +115
Лайки
+137
Дизлайки
-22
Я лайкал: +43
Я лайкал
+45
Я дизлайкал
-2
Комментарии
Комментировал: 144
Посты
11
Комментарии
133
Ответы: 156
Посты
94
Комментарии
62
Простой, легкий и мощный WYSIWYG текстовый редактор для Laravel - Summernote
dddkkk писал(а):
Пытался уже по-разному и как в статье, и как у других, сохранения файла изображения не выходит. При выборе изображения ничего не происходит, изображение в редактор тоже не добавляется. Убрав callback изображение добавляется в редактор, но нужно его сохранить в файл. Не знаю, где копать. Код один в один ваш, только summernote подключен ссылкой http://cdnjs.cloudflare.com/.../summernote-bs4.js Как можно определить проблему?
Здравствуйте. А у вас на бэкенде настроен роут, который будет принимать это изображение, сохранять его на диск и возвращать назад путь к изображению? Ведь это только фронт описан в статье. Без бэкенда изображение не сохранится.
Пару слов о судебной системе Украины. Реальный опыт. Часть 1.
юл писал(а):
Kirill как можно с Вами связаться? В нашем доме тоже осбб, которое прикаждом вопросе предоставьте отчет начинает кричать и отгавкиваться.
Здравствуйте. Можете мне написать на емаил: info@cleverman.org
Laravel 5.5 и парсинг. Что такое краулер (crawler).
Andrij писал(а):
Здравствуйте. Спасибо за ответ на предыдущий коммент. Назрел еще такой вопрос, возможно сталкивались. Если страница после прокрутки до конца, подгружает дополнительный контент, можно ли как-то симулировать на crawler эту прокрутку или ajax запрос, чтобы контент который после ajax запроса появляется, тоже спарсить. Спасибо.
Дело в том, что все JS обрабатываются на стороне клиента. Поэтому стандартным способом подгружаемый контент спарсить не получится. Именно по этой причине у одностраничных сайтов (SPA) проблемы с индексацией поисковиками. Что можно сделать с этим. Можно зайти на сайт и в панели разработчика посмотреть, какой запрос убегает на сервер для получения порции свежих данных. И уже после понимания этого момента делать парсинг не фронт стороны сайта, а именно сервера, скармливая ему запросы, как вроде отрабатывает прокрутка на фронте. Но это в том случае, если запросы отдаются GET запросом.
Мое знакомство с October CMS
Linkonoid писал(а):
P.S. Чувствую посыплются после этого комментария в мою сторону «г.внослова» в адрес моего «г.внокода» ибо «г.внокомментаторы» не понимают, что своё «г.вно» как минимум не пахнет.
Да все правильно вы сказали. Действительно, все развивается, если к этому есть интерес сообщества. Для типичных задач нет смысла все писать с нуля, CMS - это хорошая альтернатива, особенно при отсутствии большого бюджета. Админка у October действительно шикарная. Но если нужно что-то действительно кастомно сложное реализовать, то лучше сразу застрелиться :))
Laravel 5.5 и парсинг. Что такое краулер (crawler).
Andrij писал(а):
Скажите, а используете ли вы proxy с этой библиотекой парсинга, если да то может уточните как именно?Спасибо.
Здравствуйте. Прокси не использовал. Все запросы напрямую с сервера происходили. Чтобы не попасть в бан, нужно соблюдать тайминги при парсинге. Как заставить работать скрипты через прокси, то не изучал этот вопрос. Скорее всего, можно как-то через curl настроить этот процесс. Но придется приличную обертку писать, для постоянной смены проксиков, плюс проверять пинги, чтобы прокси не тормозили.
Rails + Postgres + bindings
Vorchun писал(а):
Так и не понял в чем проблема. Чем запросы вида: News.where(News.arel_table[:order_date].between(Date.current-2.year..Date.current-1.year)).where.not(owner_id: nil).pluck(:id) не подходят? ведь они будут преобразованы в один sql запрос. При желании пожно и join таблице сделать и еще where добавить.
В данном примитивном примере все вы правильно написали. Хотя такой запрос с ходу не читается и нужно прилично напрячься. А теперь попробуйте собрать вот такой запрос:
SELECT (SELECT json_agg(row_to_json(agg_notes))
FROM (SELECT n.id, n.title, n.body, to_char(n.created_at, 'DD.MM.YYYY HH24:MI') as created
FROM data.notes n
WHERE n.user_id = u.id) agg_notes) as notes,
(SELECT json_agg(row_to_json(agg_projects))
FROM (SELECT p.id,
p.name,
p.description,
to_char(p.created_at, 'DD.MM.YYYY HH24:MI') as created,
(SELECT true WHERE EXISTS(SELECT p1.id FROM data.projects p1
WHERE p1.id = p.id AND p1.report IS NOT NULL)) as report
FROM data.projects p
WHERE p.user_id = u.id) agg_projects) as projects,
(SELECT json_agg(row_to_json(agg_contacts))
FROM (SELECT c.id, c.message, c.ip, to_char(c.created_at, 'DD.MM.YYYY HH24:MI') as created
FROM data.contacts c
WHERE c.user_id = u.id) agg_contacts) as contacts
FROM data.users u
WHERE u.id = :user_id;
И прошу заметить, это нисколько несложный запрос. А очень даже самый простой, по сравнению с теми, которые встречаются в проекте (по 50 строк и более). А есть запросы, где нужно вставить с десяток биндингов.

А есть еще куча запросов с такими вещами, как полнотекстовый поиск to_tsvector, to_tsquery и т.д., работа с полями (включая логику поиска) по пересечению значений из JSONB по массиву и так далее.

Никакая ORM просто не сможет собрать такой запрос, потратит кучу серверного времени на это, а что еще хуже, то может и вовсе неправильно его собрать, делая вид, что все хорошо, что приведет к скрытым и тяжело отлавливаемым глюкам. AR же очень круто и легко использовать для загрузки и сохранения разных форм. А вот для логики в БД она вообще ни разу не подходит.

При моем же подходе, я создаю папку репозитарий, где храню статические классы с методами, которые возвращают подготовленный запрос. Например:
# Repository for mailings
class MailingRepository
# Get all emails with LIMIT and OFFSET
def self.emails_limit
'SELECT
e.id,
e.email,
e.status,
e.action,
e.updated_at::timestamp,
(SELECT json_agg(row_to_json(agg_groups))
FROM (SELECT eg.group_id
FROM mailing.emails_in_group eg
WHERE eg.email_id = e.id) agg_groups) as groups
FROM mailing.emails e
ORDER BY e.id DESC LIMIT :limit::int OFFSET :offset::int;'
end
end
Этот запрос забирает с базы все адреса (с лимитом) и создает поле с JSON, куда поместятся все группы, к которым привязан адрес.

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

Чем такой подход хорош. Все ваши запросы полностью отделены от кода и логики. Вы в любой момент можете его просмотреть и отрефакторить. А сам код не перегружен десятками методов из AR, что делает его более чистым и читаемым.

Почему я так делаю. Все просто. Я более 15 лет занимаюсь разработкой и уже давно дошел до того состояния просвещения, когда стал четко понимать, что все рекомендации и бест вэй от разных ЯП и фреймворков - это не более, чем дань моде и трендам. Самое главное - это архитектура. И она должна быть слабосвязанная, разбитая на разные законченные логические части (модули/классы). С простым и читаемым кодом, и при использовании фреймворков нужно по максимуму использовать возможности нативного ЯП, а не фреймворка, так как это даст в последствии возможность перенести свой код на другую платформу без потрясений.

Например, завтра понадобится перенести проект с Рельсов на что-то другое, и у меня с этим проблем не возникнет, так как вся логика запросов написана на нативном Postgres. Тем же, кто полностью отдался AR, придумывая для нее тонны костылей, поимеет с миграцией громадный геморрой, в виде полного переписывания всех запросов под новые реальности платформы.

У такого подхода есть и недостатки. Это необходимость глубокого понимания работы БД, и большой практический опыт построения слабосвязанных модульных систем (то есть глубокое понимание архитектуры разных процессов), что очень сильно повышает порог вхождения. Но тут уже все будет зависеть от уровня и сложности построения проекта. Если это новостной сайт или блог, то может можно и не запарываться с этим. А вот если это сложный аналитический комплекс, с кучей математических вычислений, то без построения абстрактной архитектуры, проект уже через месяц превратится в не читаемый набор из тысяч файлов, где любое исправление в коде может привести к падению всего проекта.

Надеюсь, что я донес свою мысль :)
Твой код говно! Не исходите на говно! Про Ларавел Ру сообщество.
oleg_x писал(а):
Вопрос собеседований - это вообще большая и грустная тема, особенно в отечественных реалиях Я тут подумал не плохая тема может у тебя в блоге может еще где то. Как ты думаешь?
Да, могу на выходных написать ))
Что выбрать для проекта CMS или Framework?
oleg_x писал(а):
Полностью согласен, но я не жалею что работал на CMS очень полезный опыт )
Полностью согласен. Этот опыт пригодится всегда. Иногда я вижу, что люди, которые никогда не работали с CMS, а только с фреймворками, при постановке задачи создать подобную систему, изобретают жуткие велосипеды и коллекции граблей. Что даже кровь в жилах стынет. Так что опыт однозначно полезный.
Твой код говно! Не исходите на говно! Про Ларавел Ру сообщество.
oleg_x писал(а):
код на гите https://github.com/OlegTalyatKelpsh/news_list
Глянул быстро код. Могу с уверенностью в 100% сказать, что придолбались к код стайлу и закомментированному коду. В принципе, там больше ничего и нет такого. Простые связи в моделях, тонкие контроллеры.

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

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

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

Честно говоря не знаю, как в других специальностях, так же или нет, но в ИТ присутствует нездоровая токсичность, которая мешает и жить и развиваться. И как пример, на счет того же ларавел сообщества. Там один анонимный товарищ начал говном кидаться на мое решение (мол он такой крутой и умудренный опытом). А через неделю я его увидел в общем чате, где он спрашивал, где можно джуном устроиться, мол он только учится, и хочет попробовать работать. Тут вообще без слов. И таких море.
Твой код говно! Не исходите на говно! Про Ларавел Ру сообщество.
oleg_x писал(а):
Очень полезная статья, мне она очень пригодилась в плане понимания некоторых вещей общения программистов, спасибо!
Пожалуйста ))