https://www.youtube.com/watch?v=FjlKVgUi9J8

Какие вопросы для "джуна"

этого чувака правда пускают людей собеседовать?)

вроде он хотел делать шоу какой то,Показать как много он знаеть )

"е-бизнесс"

специалисты по ООП, подскажите, это нормальный дизайн когда контроллер инжектит себя в вид (скорее даже в «контроллер своих видов») по двум разным интерфейсам?

а почему интерфейсы разные-то?

у них разное назначение: один для гета всякой информации, другой скорее для IOC

LevelController : ILevelInfo, IPlaymodeController

назначение у них как бы одно: рендеринг результата)

IVeryBadConvention, VeryBadConventionImpl

IVeryBadConvention, VeryBadConventionImpl

UselessSuffixInterface better?

UselessSuffixInterface better?

Awful.

agreed :)

agreed :)

соглашался?

конечно

но так и не согласился?))

согласен, завершённая форма :)

обчного ps достаточно

wtf is ps?

present simple

я еще is забыл в первой фразе.

мы ж не нэйтивы

мы ж не нэйтивы

если бы я был занудой, то спросил бы зачем тогда использовать неродной язык в ситуации где нет необходимости, но я не и не буду ? с наступающими выходными!

если бы я был занудой, то спросил бы зачем тогда использовать неродной язык в ситуации где нет необходимости, но я не и не буду ? с наступающими выходными!

я ж в ответ на явно содержащие английские выражения названия класов :)

кароч ты зануда :)

????

chill out guys, давайте не сориться in this chat

курс английского на канале

да мы не ссоримся :)

взрослые ж люди

кстати, взрослые люди, еще чутка полуофтопа: а скажите плз по-быстрому, использовать гет параметр для уточнения содержимого некого списка отдаваемого API, является нарушением REST или нет? что-то я вдруг засомневался... ☺️ прмер: /api/cost_center_list?division_id=22 ну или докой киньте в меня если есть под рукой

вот опять люди страшно боятся нарушить каноны святой религи под названием REST. У которой много толкователей. часто разных мыслей.

/api/division/22/cost_center_list

но похрену, REST всё равно достаточно плох

во! первый толкователь подьехал :)

вот опять люди страшно боятся нарушить каноны святой религи под названием REST. У которой много толкователей. часто разных мыслей.

я скорее про какие-то очевидные вещи спрашивал, типа так не надо, потому что тогда будет вот так

/api/division/22/cost_center_list

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

ну для меня абсолютно нормальны параметры для листа как query string. параметров может быть много. есть некоторые любители делать /param1/param2

это ужасно

да, параметров может быть произвольное пересечение, тогда им не в адрес, а в query string

это ужасно

вот как бы да, мне тоже это weird кажется ?

ок, спасибо. тогда не ипу мозг и делаю в query string

ну для меня абсолютно нормальны параметры для листа как query string. параметров может быть много. есть некоторые любители делать /param1/param2

это же не идентификаторы чтоб в урле держать, не?

из реста помню такое GET /units/id - получить ресурс DELETE /units/id - удалить его GET /units/deleted/id - получить удаленный ресурс DELETE /units/deleted/id - восстановить его ?

REST это кара за то что не смогли договориться по поводу нормального формата

В нём плохо буквально всё

REST это кара за то что не смогли договориться по поводу нормального формата

Начиная с названия

Вот да

REST это кара за то что не смогли договориться по поводу нормального формата

А что есть нормальный формат?

Есть чуть менее днищенские)

REST это кара за то что не смогли договориться по поводу нормального формата

жиза)

Действительно, интересуют форматы. Особенно если они не поверх HTTP работают.

Есть чуть менее днищенские)

Конкретнее, пожалуйста.

Конкретнее, пожалуйста.

Ща OData заедет, либо GraphQL

Заметьте, не я это предложил

Действительно, интересуют форматы. Особенно если они не поверх HTTP работают.

Форматы должны быть protocol agnostic

Форматы должны быть protocol agnostic

Жду конкретные названия :)

REST это кара за то что не смогли договориться по поводу нормального формата

REST в принципе и не формат совсем.

Жду конкретные названия :)

тебе выше уже дали. + сверху grpc и прочие штуки.

REST это архитектурный стиль который был использован для WEB. По поводу как узнать rest или не rest - если тебе для добавления какого-то метода API надо хоть что-то править на клиенте - это не rest а просто rpc via http (юзаешь ты там чето свое, юзаешь ли http как протокол апликейшен уровня или транспортный, или ты юзаешь тот же gprc, или odata или graphql.... суть одна и та же).

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

ну то есть не пытаться всякими там HATEOAS обмазаться (всеравно не выйдет, разве что ты браузер напишешь), а просто сделать удобно.

REST это архитектурный стиль который был использован для WEB. По поводу как узнать rest или не rest - если тебе для добавления какого-то метода API надо хоть что-то править на клиенте - это не rest а просто rpc via http (юзаешь ты там чето свое, юзаешь ли http как протокол апликейшен уровня или транспортный, или ты юзаешь тот же gprc, или odata или graphql.... суть одна и та же).

> если тебе для добавления какого-то метода API надо хоть что-то править на клиенте - это не rest Это значит — добавление нового метода не затрагивает работоспособность старых или — можно добавить новую функциональность в клиент, не изменяя его? Первое звучит как заведомо истинное, второе — как заведомо ложное, безо всякой привязки к REST.

угу, тот же вопрос

> если тебе для добавления какого-то метода API надо хоть что-то править на клиенте - это не rest Это значит — добавление нового метода не затрагивает работоспособность старых или — можно добавить новую функциональность в клиент, не изменяя его? Первое звучит как заведомо истинное, второе — как заведомо ложное, безо всякой привязки к REST.

я это больше говоря к вопросу что не может быть rest api. Rest это про unified interface и code on demand если unified interface не закладывает какие-либо детали поведения. То есть пример rest-а банален. Ты открываешь браузер, и заходишь в гугл. Тебе высвечивается форма. Браузер умеет эту форму показывать но в сам браузер не вшито ничего специализированного чисто под эту страничку. Ты жмакаешь "искать" и происходит переход (то что подразумевается под State transfer из аббривиатуры REST). Там ты видишь уже новую страничку опять же о которой браузер ничего не знал до этого. И там ссылки на другие странички и т.д. То есть идея в том что бы все знания о том как пользоваться чем были инкапсулированы на сервере а клиент лишь знал как отображать те или иные штуки (или же опять же, если мы хотим отобразить сложную форму фасеточного поиска которая по хитрому формирует запрос - мы можем воспользоваться code on demand и вшить javascript код в страничку что бы та чего машнила). Вжух в результате всего этого мы имеетм web. То есть бесконечно скейлящаяся система, для которой не нужно версионирование (разве что для протоколов оно все же надо), где все работает за счет content negitiaton, гипертекста, hateoas. URI и прочих стандартов которые в сумме и дают тебе WEB. А когда ты делаешь приложение мобильное или SPA ты уже не с гипертекстом работаешь. Ты работаешь с фиксированными структурами данных, обычно в виде json. И так или иначе твое приложение должно знать что-то о сервере. Обычно ты все эндпоинты так или иначе хардкодишь. Я видел попытки сделать autodiscovery для API но в этом случае всеравно тебе надо на клиенте запилить че как дискаверить + всеравно есть структуры данных которые фиксированные.

подкреплю мысль вот такой картинкой:

https://twitter.com/fielding/status/324448353180061696?lang=en

p.s. есть целая гильдия людей которые считают что "то как реализован web если еще более-менее хотя тоже дно, но мобильные приложения это возвращение к подходам из 80-х"

p.p.s. когда человек говорит "rest api" на данный момент времени можно будет сказать что "скорее всего в качестве транспорта будет http и скорее всего обмениваться мы будем либо json либо xml". Больше никакой конкретики.

Но так-то веб — это платформа для чтения медиума/хабра, нормальные приложения там не получаются.

Но так-то веб — это платформа для чтения медиума/хабра, нормальные приложения там не получаются.

ну как сказать не получаются.... я бы сказал что не особо пытаются ну и в целом не пытаются потому что все это слишком сложно (+ а как же NIH индром?)

ну и мысль моя не в том что то как сейчас это плохо - жить то надо как-то.... а в том что это не rest. Rest это как ты сказал медиумы хабры да всякие там яндекс маркеты.

web-компоненты к слову неплохая альтернатива.... но чет как-то все заглохло с ними

Что за NIH? Telegram web — такое себе, Telegram на Qt — годно. Сообщения ВК в веб — отстойно. Toggl в веб — отстойно, Toggl Desktop — урезок. Twitter в веб довольно тормозной и странный, Twitter для Android чуть менее плох.

Что за NIH? Telegram web — такое себе, Telegram на Qt — годно. Сообщения ВК в веб — отстойно. Toggl в веб — отстойно, Toggl Desktop — урезок. Twitter в веб довольно тормозной и странный, Twitter для Android чуть менее плох.

к чему ты это?

к чему ты это?

к тому, что веб не предназначен для создания приложений, это текстоориентированная штука

к тому, что веб не предназначен для создания приложений, это текстоориентированная штука

возможно, а возможно ты слишком упрощаешь то как видишь приложения)

Бредятина

p.s. я вообще не шарю, просто я не вижу разницы между spa/mobile и скажем десктопным софтом из 70-х или 80-х

Причины по которым телеграм веб — "не очень" не имеют с этими предположениями совершенно ничего общего

Причины по которым телеграм веб — "не очень" не имеют с этими предположениями совершенно ничего общего

да и телеграм web это разве не SPA?

Что за NIH? Telegram web — такое себе, Telegram на Qt — годно. Сообщения ВК в веб — отстойно. Toggl в веб — отстойно, Toggl Desktop — урезок. Twitter в веб довольно тормозной и странный, Twitter для Android чуть менее плох.

короч из твоего сообщения я могу лишь обозначить слишком неглубокое твое погружение в эту тему)

очень поверхностные суждения

без попытки хотя бы определить разницу между web приложением и приложением

p.s. я вообще не шарю, просто я не вижу разницы между spa/mobile и скажем десктопным софтом из 70-х или 80-х

Так её нет) +1 платформа, не в первый раз ?

или разобраться в чем прелесть подхода с гипертекстом и как альтернатива когда все хардкодиться на клиенте

Что за NIH? Telegram web — такое себе, Telegram на Qt — годно. Сообщения ВК в веб — отстойно. Toggl в веб — отстойно, Toggl Desktop — урезок. Twitter в веб довольно тормозной и странный, Twitter для Android чуть менее плох.

Не совсем Они там много го*** намутили с Qt

Телеграм кстати на ресте было бы жестко делать, у них огромное количество данных