Как стать автором
Обновить

Комментарии 41

А готовый код когда ждать, халявщики негодуе…

Если речь об исходниках парсера, то позже оформлю и выложу

Хотя бы одна положительная новость в понедельник!
Меня сейчас гоферы заминусят, но, если честно, пытался сделать заход в сторону GO — не вышло, обливаясь слезами я побежал обнимать свой PHP 7.1…
В GO все вроде бы круто, статическая типизация, рутины и прочее, но этот язык упорно превращает работу с массивами в кромешный ад. Да, я понимаю что это, в общем-то, плата за статичность, но, ведь, задумываясь, в большинстве случаев веб — это про массивы.
Согласен о массивах. Но, все-таки веб — это про конкатенацию строк :))
Собирать строки в массив, а потом делать его конкатенацию. Обычно так)
большинстве случаев веб — это про массивы

(икая от удивления) правда?!? Хорошо, что у меня какой-то другой веб!

Сенсей, расскажите мне, неумелому, как вы пишете бэкенд минуя работу с массивами на каждом чихе?
Ибо ну серьезно, чаще чем с массивы встречаются разве что строки (и даже это утверждение я бы подверг сомнению).
Строгая типизация предполагает, что не должно существовать абстрактных массивов. В Go это скорее объекты для размещения в памяти. Создавайте собственные коллекции. Мало того, не нужны все методы для любой коллекции, создавайте/наследуйте только действительно необходимые этой коллекции методы.
Для работы с базой есть 2 подхода: ORM или генерация кода.

P.S. Да если уж приспичило, в конце концов, написать wrapper для map дело пяти минут, да и понаписано их уже прилично.
НЛО прилетело и опубликовало эту надпись здесь

Да очень просто пишу — не используя похапе :) (ой, щас религиозные фанатики налетят). Я, конечно, понимаю, что если у вас в руках молоток, то всё на свете кажется гвоздём похапе, то всё на свете кажется массивом. Но на самом деле это не так. Собственно, это даже с похапе не так. Я на нём последний раз, конечно, аж лет 10 назад писал, но даже тогда не было необходимости в низкоуровневой манипуляцией с массивами. Не думаю, что за эти годы там всё поломали.
Ибо, ну, серьёзно, что вы такое делаете, что вам приходится постоянно что-то делать с массивами? Человече, на дворе скоро будет заканчиваться второе десятилетие двадцать первого века, принципы ООП и ООД придумали чёрт-те сколько лет назад, а вы всё с массивами. Оно, конечно, можно и так, но зачем?
ЗЫ. Однажды давно, во времена оны, два кадра в конторе, где я тогда работал, решили сделать специфическую подсистему разрабатываемого продукта. И мыслили они так же массивами. И сделали всё на массивах. После чего решили, что их программерская квалификация ускакала до небес и ушли в другую контору с повышением. А мы потом полезли в их систему… Поразительно, что она работала, но там был такой ужос-ужос с постоянными копированиями этих самых массивов из одного места в другое, вырезанием из них каких-то подмассивов, слайсов и необходимостью помнить что за хрень лежит в пятнадцатом элементе массива params… В общем, я никогда не встречал более неподдерживаемой системы. В неё немного потыркали палочкой и… всю полностью выбросили на свалку. :) И, в качестве бальзама для пехапешников — они умудрились сделать это не на пхп, а на вполне оошной яве :)

ООП и ООД придумали чёрт-те сколько лет назад, а вы всё с массивами
А не развернете ли мысль, как использование ООП/ООД избавляет от необходимости работы с массивами/векторами/списками/слайсами/тп (в разных ЯП по-разному)?

От работы с массивами не избавляет. Избавляет от ситуации "веб — это про массивы". Даёт возможность перейти к ситуации "веб — это про… (хм, ну, пусть про) всякие разные объекты" :). Где-то там внутри, разумеется, есть и массивы. Но в большинстве случаев туда лезть нет необходимости. Вот правда, можете привести примеры, когда в вебе действительно нужна постоянная нетривиальная работа именно и только с массивами? У меня вся работа это, как правило — пробежать по коллекции. Или, ещё лучше, — обработать коллекцию как стрим. Уже взятие элемента из коллекции по индексу, а не с помощью итератора — ситуация крайне редкая. А какие-то более нетривиальные действия, я вообще не могу представить для чего в абстрактном типовом "вебе" могут понадобиться (исключая какие-то узкоспециализированные задачи обработки именно массивов, но это уже больше не про веб, а про математику).
Для разработчика в машинных кодах "программирование — это про биты и адреса памяти", но языки программирования высокого уровня позволяют мыслить более высокоуровневыми объектами, поскольку в большинстве случаев это удобнее, быстрее, и тд и тп.

У меня вся работа это, как правило — пробежать по коллекции. Или, ещё лучше, — обработать коллекцию как стрим.
Любопытно, как это вы в Go обрабатываете коллекции (слайсы?) как стримы? Итераторы какие-то… непонятно :)

но языки программирования высокого уровня позволяют мыслить более высокоуровневыми объектами, поскольку в большинстве случаев это удобнее, быстрее, и тд и тп.
Я думаю про это и был изначальный посыл. Мол в Go дефолтные массивы/слайсы заставляют работать с ними «на низком уровне», что для web весьма неудобно.

Да не, человек, вон, пишет, что вернулся на похапе, тк там с массивами хорошо работать, а "веб — это про массивы". Не с высокоуровневыми объектами хорошо ему на похапе, а с массивами. ;) Ну, нравится людям мучиться, кто я такой, чтобы настаивать? Не хотят — да и пусть с ними.

Да, недокументированные фичи очень часто оказываются полезными. Причем зачастую создается ощущение, что разработчики начали их введение, но на полпути решили «позабыть» про них
C организацией кода в Golang все просто: «Вот тебе директория, заодно это и неймспейс, кстати. Держи все здесь». И… Это работает. Это настолько просто в разработке и поддержке, что слезы счастья наворачиваются сами собой.

Я, кстати, не понимаю, чем всем нравится такой вариант. То есть я понимаю преимущества по сравнению с c++, но причин отсутствия менеджера зависимостей и какого-то формата пакетов и так и не понимаю. И не то, что бы это сложно для go, тот же dep есть и вполне работает, вот только не все используют его.

Что вы подразумеваете под менеджером зависимостей?
По факту, все инклюды в Go сводятся к двум кейсам: либо у вас какой-то частично обособленный кусок проекта лежит в подпапке, и единственная точка пересечения у вас с ним — это канал и вызов одной-двух публичных процедур. Важным является то, что вы почти безболезненно можете это дело вынести в отдельный сервис, когда его понадобится крутить на отдельной машине. Либо (что тоже самое) это либа, загружаемая из VCS репозитория.
Я кстати про инклюды вообще не думаю, у меня Gogland, он сам за меня всё что надо добавляет, стоит только начать писать например sqlx.Get(, и sqlx уже добавился.

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


Что-то похожее предлагает dep, вот только проблема в том, что далеко не все даже релизами пользуются. Например, с какого-то перепугу ими перестал пользоваться moby.


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

пробовали разное в большом проекте. в итоге glide пока наиболее стабильное решение, простое и удобное. порядка 2х лет в продакшене на примерно 60 микросервисов работает без нареканий.
Как уже говорили в чатике телеграма: к сожалению, неважно, насколько вам нравится glide, dep уже стал почти официальным менеджером зависимостей, так что с glide пора валить и тем более не начинать на нем проекты. Даже автор glide так говорит в readme.
Это так, но есть старое-доброе «работает — не трожь», и хотелось бы хотя бы полгодика посмотреть на dep после prod release перед тем, как затевать переходы.
Пока есть ряд опасений насчет него, особенно касаемо политики разработчиков golang «ты не хочешь эту фичу».

Менеджеры есть. И полно. Начиная с примитивного встроенного go get.


Вы имеете ввиду что среди них нет некого и крутого и стандартного одновременно?


Если вам для своей разработки — выберите какой нибудь из имеющихся и используйте

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

Горутины — это удобная параллельность из коробки

тут слово параллельность лучше заменить на конкурентность, достаточно разные вещи.
Добрый день. На выходных востанавливал работоспособность гема, зашёл на хабр а тут такое. Через апи нет таких проблем с парсингом, алгоритм подписи можете подсмотреть в коде(ребята из команды Кинопоиска, не кидайтесь тапками, лучше сделайте публичный API).
Я действительно находил решения для работы с их мобильным API (возможно, именно, ваше). Однако, я отказался от этого пути в пользу парсинга сайта и вот почему:

  • В случае изменений на API, надо отлаживать трафик приложения, трафик сайта отладить проще
  • В случае изменений на API, доступ к информации, пропадет полностью, в то время, как при изменении сайта парсер может не найти какой-то информации, но большую часть разберет
Не спорю, что всё не официально и работает на честном слове, но все-таки изменить быстро АПИ они не смогут, иначе старые версии надо принудительно обновлять, а для этого нужно время. Если поддерживать и следить за новыми версиями приложениями, то будет работать относительно стабильно.

Я немного забросил этот гем т.к. не было нужды в нём, но на выходных решил сделать. Пока все тесты проходят(travis дергает каждые сутки), теперь я буду знать когда лавочку прикроют :).
Помню, когда встала задача слить БД кипоноиска я посматривал на то самое уже закрытое неофициально апи (оно кстати переродилось в аналогичный вашему модуль для пхп) и решил парсить сам. Как показало время — решение было верное.
Задавал этот вопрос и владельцу старого апи, задам и вам — не проще ли спарсить сразу всю БД и актуализировать её в фоне, а запросы собственно делать к своим данным?
Это будет и надёжнее и быстрее, ну и разделить ответственность позволит. Судя по запросам в вашем геме там на всё про всё выйдет 2-3кк запросов к КП для начала ну и на актуализацию сколько то, в зависимости от периодичности.
Лишних данных не бывает, надо делать отдельный сервис.

Только его надо поддерживать, если есть спрос то почему бы и нет, но для меня уже не так актуально. Я только восстановил библиотеку, чтобы она работала.
Для ноды есть zombieJS аналог газла тока еще более глубокий, он даже js выполняет на странице, без запуска хеадлес браузеров.
А вообще из всех аналогов запускающих браузер мне больше понравился puppeteer, он специальзируется исключительно на хроме, из плюсов в нем поддержка всех видов проксей, с другими я очень много возился чтобы хоть какие то запустить.
Да еще хотелось бы взглянуть на вашу очередь проксей, и вопрос к сообществу есть ли какие то готовые менеджеры таких очередей, чтобы загружаешь и оно само все проверяет и выдает тока самые актуальные которые недавно проверялись.
Сейчас в своем столкнулся с тем что, анонимность прокси невозможно проверить если она не работает для российских ип, так как она проверяется тока направляя на себя. Тоесть через неё можно работать но до меня она не конектит.
Только зобми и есть безголовый браузер (https://github.com/assaf/zombie), поэтому он и зомби, я полагаю )
Golang хорош ровно до тех пор, пока на нём не приходится писать REST API(по моему мнению). Вот где начинается дикая жесть, попытки городить костыли чтобы обойти ограничения языка.
Хотя сам язык мне нравится, писать на нём удобно и приятно. Но дико не хватает дженериков и enum'ов
странное дело, удалось несколько REST-сервисов написать, для начало «ради фана», в результате понравилось, правда без фреймворков, брал стандартные пакеты, за исключением для работы mysql…

какие ограничения имеются в виду? Интересно узнать
Под каждый ресурс необходимо генерить свой type struct. Например, если есть объекты user(s), record(s), etc, под каждый из них по-хорошему должен иметься
type User struct{}
type Record struct{}

Потом, когда нам приходит запрос на вход(POST, PUT), мы должны валидировать эти запросы. Для этого, по-хорошему, входящие JSON-структуры нужно засовывать во что-то типа map[string]interface{}, чтобы работать с сырыми данными. И вот в этом случае мы приходим к пакету reflect, с его крутыми возможностями, но, в то же время, с дичайшим оверхедом в коде, т.к. приходится вручную ползать по этим срезам с интерфейсами и смотреть, что же мы получили на входе.

Это язык со статической типизацией — да конечно делать структуры.


Рефлект вам не нравится? Так ведь языки с динамической типизацией так же примерно как рефлект и делают. Причем все. Вообще все.


Попробуйте RawMessage из стандартного пакета encoding/json, может в вашем случае поможет

reflect замечателен, дело не в этом. Дело в том, что приходится городить слишком много ручного кода для обработки кортежа интерфейсов.
Если использовать паттерны из динамических языков в языках статических — да.

Разумеется динамические языки требуют меньше кода в таких ситуациях, потому они и широко распространены. Но статические требуют меньше проверок.

В сумме не выходит столь уж огромной разницы. Просто не тяните в статические паттерны из динамических
обычно для валидации входящих делаю unmarshal для json, и если json размаршился валидно, проверяю нужные элементы структуры… емейл должен быть емейлом, user.username не должен быть пустым и т.п.,

тоже самое с REST-api на php: данные получил, корректность полученных данных проверил, не вижу особой разницы в подходе… можно конечно валидаторы внедрять, типо:

bodyStruct := struct {
FirstField string `json:"first_field" validate:"string,require"`
SecondField string `json:"second_field" validate:"int"`
}{}

bodyByte, _ := ioutil.ReadAll(request.Body)
json.Unmarshal(bodyByte, &bodyStruct)
validate(&bodyStruct)


и паниковать если валидация не проходит, или errors.New() выплевывать… все ограничивается фантазией :)

структуры\классы в любом случае удобней ассоциативных массивов, и в ИДЕ сразу выплевывает возможные свойства, и меньше возможности сделать опечатку и дебажить потом целый день «почему юсернейм не сохраняется».

А почему вы вообще решили парсить кинопоиск, а не работать с api themoviedb.org, где у большинства фильмов есть русское описание и постеры. Я думаю это сэкономило бы уйму времени.

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

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории