Комментарии 41
В 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 обрекли нас на версионность по коммитам. Очень сочувствую тем ребятам, которым это нравится.
Менеджеры есть. И полно. Начиная с примитивного встроенного go get.
Вы имеете ввиду что среди них нет некого и крутого и стандартного одновременно?
Если вам для своей разработки — выберите какой нибудь из имеющихся и используйте
Горутины — это удобная параллельность из коробки
тут слово параллельность лучше заменить на конкурентность, достаточно разные вещи.
- В случае изменений на API, надо отлаживать трафик приложения, трафик сайта отладить проще
- В случае изменений на API, доступ к информации, пропадет полностью, в то время, как при изменении сайта парсер может не найти какой-то информации, но большую часть разберет
Я немного забросил этот гем т.к. не было нужды в нём, но на выходных решил сделать. Пока все тесты проходят(travis дергает каждые сутки), теперь я буду знать когда лавочку прикроют :).
Задавал этот вопрос и владельцу старого апи, задам и вам — не проще ли спарсить сразу всю БД и актуализировать её в фоне, а запросы собственно делать к своим данным?
Это будет и надёжнее и быстрее, ну и разделить ответственность позволит. Судя по запросам в вашем геме там на всё про всё выйдет 2-3кк запросов к КП для начала ну и на актуализацию сколько то, в зависимости от периодичности.
А вообще из всех аналогов запускающих браузер мне больше понравился puppeteer, он специальзируется исключительно на хроме, из плюсов в нем поддержка всех видов проксей, с другими я очень много возился чтобы хоть какие то запустить.
Да еще хотелось бы взглянуть на вашу очередь проксей, и вопрос к сообществу есть ли какие то готовые менеджеры таких очередей, чтобы загружаешь и оно само все проверяет и выдает тока самые актуальные которые недавно проверялись.
Сейчас в своем столкнулся с тем что, анонимность прокси невозможно проверить если она не работает для российских ип, так как она проверяется тока направляя на себя. Тоесть через неё можно работать но до меня она не конектит.
Хотя сам язык мне нравится, писать на нём удобно и приятно.
какие ограничения имеются в виду? Интересно узнать
type User struct{}
type Record struct{}
Потом, когда нам приходит запрос на вход(POST, PUT), мы должны валидировать эти запросы. Для этого, по-хорошему, входящие JSON-структуры нужно засовывать во что-то типа map[string]interface{}, чтобы работать с сырыми данными. И вот в этом случае мы приходим к пакету reflect, с его крутыми возможностями, но, в то же время, с дичайшим оверхедом в коде, т.к. приходится вручную ползать по этим срезам с интерфейсами и смотреть, что же мы получили на входе.
Это язык со статической типизацией — да конечно делать структуры.
Рефлект вам не нравится? Так ведь языки с динамической типизацией так же примерно как рефлект и делают. Причем все. Вообще все.
Попробуйте RawMessage из стандартного пакета encoding/json, может в вашем случае поможет
Разумеется динамические языки требуют меньше кода в таких ситуациях, потому они и широко распространены. Но статические требуют меньше проверок.
В сумме не выходит столь уж огромной разницы. Просто не тяните в статические паттерны из динамических
тоже самое с 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, где у большинства фильмов есть русское описание и постеры. Я думаю это сэкономило бы уйму времени.
Golang, PHP, Кинопоиск и Telegraph — Что их объединяет?