Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+74
List<CurrentRegion> currentRegionsFromDb = impl
.getAll(CurrentRegion.class);
if (currentRegionsFromDb.size() != 1) {
throw new FillReportException();
}
CurrentRegion currentRegion = (CurrentRegion) currentRegionsFromDb
.toArray()[0];массив головного мозга
Запостил: 
evg_ever,
29 Января 2014
Follow us!
Нужно написать кроссплатформенный браузер? Плюсы. Толстого клиента для венды? ну, видимо, шарп или плюсы с Qt. Нужен веб сайтик? ну вы понели.
В контексте высоконагруженного сервер-сайда у нас в местных бложиках до сих пор страсти не утихают. Когда есть интересная задача и есть ресурсы для её решения, плюсы весьма неплохо себя показывают. Многие пищат, что мол в жабе всё так просто, может, ну их эти плюсы? Я эту позицию не разделяю. "Простота" жабы часто выходит боком, когда нужно решать нетривиальные задачи. Да и порядком напрягает уже ковыряться в сотнях спринговых конфигов.
С другой стороны, невероятно удручает текущее состояние инфраструктуры C/C++. Нормальных кросс-платформенных сред разработки - нуль. Удобных систем сборки с convension over configuration - нуль. Вменяемых систем пакетирования - нуль.
Недавно пытался вникнуть в autotools, тошнило кровью.
я имел в виду при прочих равных. У нас же есть цари, которые кроме крестов ниче не признают. А по итогу качество не лучше, чем на жабе, плюс разбитый в кровь анус. теперь я понял что значит плюс плюс
А вообще - полностью с тобой согласен
не, цари признают только gcc
Бинарник, генерящий говноскрипт, который после правки компилится в говноскрипт исполняющий говноскрипты на целевой машине, и подставляющий значения в сгенеренный бинарником из говноскрипта говноскрипт, который будет собирать прогу...
Вроде бы ничего не забыл из комплекта автотулзов ;)
fixed
Одна из команд, к примеру, пишет кросс-платформенное нативное ядро для всех популярных мобильных платформ с единым набором сервисов. Разумеется, на с++.
Может это сам спринг - говно.
Имхо, мегабайты xml конфигов - отвратительная вещь.
Вот в других же языках абсолютно свободно обходятся без них.
>>о пытался вникнуть в autotools, тошнило кровью
Схожие ощущения. Вообще не пойму зачем было сделано ЭТО.
"make it easy" там и близко не пахент.
- мне не надо, что бы сделал, мне надо что бы ты заебался
Да жуткая распиаренная монстролиба, не совсем понятно почему она так популярна.
>> аннотаций хватает для описания.
Сейчас и в спринге можно аннотациями.
PS интересно кто минуснул пост выше.
плюс
- то, что они ближе к коду, на который они влияют.
минус
- отладчик их не понимает.
- копипаста. На сколько плохо задумано и реализовано повторное использование кода в Яве, аннотации только усугубляют проблему. Они не наследуются. У них уебищный синтаксис, который понимает только небольшую часть синтаксиса Явы. Их можно применять только в определенных местах (нельзя применить к локальным переменным, например).
О, опять же, вспомнил, умное слово: аннотации это разновидность string-programming.
Зачем?
Ага, передаем клиенту сотню тысяч записей, в которых половину полей ему по роли видеть вообще не положено. Пускай отсеивает ;)
Да и причем здесь это?
wvxvw все-таки об обработке ресурсов с одним request path разными контроллерами в зависимости от ситуации (в частности от роли юзера). Т.е. guest заруливается в один контроллер, manager во второй, а customer в третий. И каждому достается различный функционал, соответствующий его роли.
Ну так формируем данные относительно роли в одном и том же контролере или аякс, не? Или я что то не понял?
>> Проще на стороне клиента делать отсев.
я имел в виду что то типа "зарегестрируйтесь что бы посмотреть это сочное видео про лезбиянок" серверу пох, он одно и тоже отправляет, а JS решает будет ли человек наслаждаться лезбиянками или нет
так то я нуб, че
Если раздавать зашифрованные видео, а ключи предоставлять только авторизованным пользователям.
Если выбрать достаточно медленный алгоритм шифрования, можно по пути избавиться от назойливых смартфонов.
Телефон должен звонить, а не заменять планшеты.
Более тривиальная задача: модератор, администратор, зарегистрированый пользователь, гуглобот и незарегистрированый пользователь пришли на форум по одному и тому же пути. Совсем не хочется их всех обрабатывать в одном месте.
нет.
Что-то это уже больше похоже не на REST, а на традиционную генерацию HTML портянки на серваке...
Имхо REST way:
/бюджет/подразделения - получаем список подразделений (по идее доступно всем кроме гостей)
/бюджет/подразделение/<номер> - операции над конкретным подразделением (доступно диру и бухам данного подразделения)
Как правило различие в ролях не ограничивается различием в одной функции, и поэтому если использовать if'ы, мы будем проверять то же условие много раз.
Что до организации /отдел/под-отдел/бюджет, или /бюджет/отдел/под-отдел - это плохо, т.как заставляет на уровне интерфейса включать информацию о структуре организации (а что если отдел расформируют, назовут по-другому, переназначат другому ведомству?). Для человека нормально ожидать, что программа с которой он общается сможет дать правильный ответ удовольствовавшись minimal and sufficient condition. Т.е. регистрируясь на рейс, мы ожидаем от регистратора, что только сообщив ему свой номер паспорта, вся дальнейшая процедура будет выполнена автоматически, вместо того, чтобы указывать номер рейса, авиакомпанию, бортовой номер самолета осуществляющего перевозку, номер кресла, имя пилота и т.д.
Почему РЕСТ и УРЛ? - потому, что это пример интерфейса предоставляемого пользователю программой.
Приложение не должно ничего генерировать за пользователя. Это экстенсивный путь развития, который скорее рано, чем поздно упрется в то, что логика генерации станет необъятной вещю в себе.
Приложение должно понимать пользователя руководствуясь минимальной необходимой информацией.
REST API - это нихрена не интерфейс, предоставляемый пользователю. Он передает чистейшие данные от одной программы другой. Разве не так?
используй rest так, как его следует использовать
пока что выглядит так, что ты хочешь, чтобы и мухи, и котлеты, и бюджет за десятилетие приходил через http://mydoma.in/godmethod - просто на основе того, как сложились звёзды
это порочная практика даже не в веб, а вообще везде
Например, существует интерфейс налоговых накладных, не привязаный к контретным организациям обменивающихся средствами. Или интерфейс штекера и розетки.
Хорошее планирование заключается в нахождении минимальных интерфейсов, способных предоставить максимум информации. С этой точки зрения интерфейс /бюджет/отдел/подотдел - избыточный, т.как требует передачи данных уже имеющихся в его распоряжении.
Проблема универсального молотка не в том, что он универсальный. Более того, это было бы замечательно, если бы такой молоток существовал. Проблема в том, что человек утверждающий, что у него есть такой молоток, скорее всего врет.
1. Надеюсь, это очевидно, что получить доступ к бюджету организации в любом случае потребует авторизации.
2. Есть два разных вопроса, которые можно задать программе управляющей финансами организации:
- какой бюджет у меня?
- какой буджет у отдела Х, подотдела У, бугхалтера Й?
3. В первом случае, вы спрашиваете у программы: /бюджет?, во втором: /бюджет/х/у/й?
Глупая программа заставит вас всегда задавать второй вопрос, не в состоянии ответить на первый, но человек, работающий в той же огранизации, в отличие от глупой программы, всегда сможет дать вменяемый ответ и на первый вопрос тоже. Более того, у человека, выполняющего роль программы отвечающей за бюджеты возникнет когнитивный диссонанс, когда вместо того, чтобы спросить у него: "Какой у меня буджет?" вы спросите "Какой буджет у бухгалтера, работающего в том же тоделе, что и я, в одном подотделе со мной, и регистрационным номером таким же как у меня?"
В этот момент он в уме производит следующие действия:
1) Если мне не изменяет память, это Вася Пупкин.
2) Вася работает бухгалтером в отделе X подотдела Y.
3) Раз он не попросил что-то более конкретное - значит ему нужны бумаги по его отделу.
В спринге, если я не туплю (я с ним не работал) можно в контроллере для "/бюджет" проделать те же действия и вернуть "forward:/бюджет/X/Y", который сделает внутренний редирект на другой контроллер.
> Какой буджет у бухгалтера, работающего в том же тоделе, что и я, в одном подотделе со мной, и регистрационным номером таким же как у меня?
Ну не надо утрировать... /бюджет/отдел/5/подотдел/7 это всего лишь "Дай мне бумаги по бюджету отделу 5 подотдела 7". А это вполне адекватный вопрос, с которым любой бух справится. Ну разве что вместо цифр будут человекочитаемые названия, в духе "отдел продаж" или "отдел IT".
1. Какой у меня буджет? (программа меня уже знает, если бы не знала, я бы даже вопрос задать не мог).
2. Какой буджет у Пэти из отдэла Х? (случайно может получиться так, что Пэтя из отдэла Х, это снова я).
Но если бы человек себя вел так, как программа, которая не понимает вопрос #1, то его бы в корридорах заведения, где он работает называлибы пидарасом, потому что он заставляет остальных общаться с ним через жопу.
Просто нам как бы привычно, что программы пишутся так, чтобы минимизоравать возможности по общению с ними, и мы себя приучаем к тому, чтобы общаться с ними извращенным способом.
Да, да самое то, редиректами это решить. Посылать ХТТП запросы с одного сервера на него же. А еще лучше через мета таг ХТМЛ странички которую отдать незамысловатому пользователю (мой провайдер, например, так поступает, и пох, что запрос пришел не от браузера).
В чем проблема? Просто уточненный запрос уйдет на обработку другому контроллеру.
> программа, которая не понимает вопрос #1
Ваш вариант - чтобы фреймворк искал все доступные контроллеры для данного вопроса (если у юзера не хватает прав или чего-то еще - контроллер недоступен), и выбирал из них наиболее вероятный, а остальные показывать как "возможно вы имели в виду" или "см. также"?
2. Нет, ничего не нужно искать, эта техника уменьшает количество проверок. Читать выше про csp.
Какой кабель, если я не туплю, там создастся пара объектов да пробросится на диспатчер того же самого спринга, даже за пределы процесса не уйдет ;) Если уж и жаловаться - так на потребление проца и нагрузку на gc.
> Читать выше про csp.
А чем это отличается от того, о чем я написал? Я же в этом предложении и писал про то, что фреймворк выбрал контроллеры, удовлетворяющие ограничениям (т.е. решал ту самую задачу CS, как он это делает - не суть, пусть для простоты будет полный перебор и проверка всяких аннотаций). Но вот у задачи, внезапно, оказалось несколько решений (вдруг некоторым бухам разрешили смотреть как свой так и общий). Что делать дальше? :)
Напомним, вы писали:
> Ваш вариант - чтобы фреймворк искал все доступные контроллеры для данного вопроса.
Отличается тем, что искать ничего не нужно. Сам факт логина выбирает нужный контроллер, и больше никогда ничего не ищет. Почувствуйте разницу: никогда и искал все.
Еще раз, если вы вдруг очень быстро читаете: никто ничего не ищет. Задача удовлетворения констрентов решенная лучшим возможным образом гарантирует, что вы проверяли только необходимые условия, минимальное количество раз. Этого требует определение задачи: sufficient and necessary condition.
Ну и для закрепления: если мы уже знаем, кто попросил свой бюджет, зачем этого человека спрашивать о том, где мы храним его бюджет? Он может и не знает даже. Люди всегда стараются минимизировать бюрократию необходимую для получения сведений до передачи только минимальо необходимых данных. Прийдя в библиотеку, мы не рассказываем библиотекарю на какой полке какого стелажа в каком архиве стоит нужная нам книжка. А если мы будем рассказывать в подробностях таксисту как лучше доехать, то можно и не доехать.
-----
Подытожим:
Никаких форвардов, полузащитников, редиректов, почистить кукис браузером не нужно. Если вы это делаете, вы, очевидно, используете Спринг, ЦМС или Варп-рес.
А что юзают труъ программисты?
Решения для ж.скрипт игрушек основаных на ВебСокетах мне еще не попадались, или только кустарщина.
Для веб игрушек?
После года работы они случайно обнаружили, что сами хостили XMPP сервер, который работал как прокси между Лицокниговским чатом и нашими пользователями. Когда я увольнялся оттуда, компания как раз праздновала миллионного зарегистрированого пользователя.
Так вот, интересная деталь. Сервер, на котором работал этот прокси вообще даже его никогда в top не показывал. Его нашли "случайно", когда решили обьединить видео и текстовый чат на одном сервере и вдруг поняли, что ФМС такую нагрузку никогда не потянет. Потом хотели написать XMPP клиента на Флеше, а потом забили и так и оставили.
Есть один "странный" момент, что почти никто не догадался эти сервера использовать для игрушек. Просто исторически игроделы и питонисты, видимо, не пересекаются. И игроделы делятся на несколько груп:
- самородки (пишут все сами). Конгрегат, Мочи и т.д.
- богатые (покупают Юнити / ФМС / Электросервер). Всякие онлайн казино и т.п.
- сообразительные (находят подходящие бесплатные компоненты). Инди разработчики, типа Машинариума.
кроме того, fat server, что олицетворяет весь пхп, да и питон в основном - это вчерашний день
Можно встать на рельсы ;)
А я люблю обмазываться несвежим говном и дрочить...
Не, как CMS джумла очень даже хороша. Если тебе надо слепить сайтик за пару дней, а потом регулярно менять на нем контент. Даже пару-тройку своих компонентов можно запилить...
Но юзать джумлу как фреймворк для разработки веб-приложений - немного не то.
вообще не то.
с 2 способа общаться -
1 сайты делать - тады хочешь компонент - в гугл, нечего придумывать ересь
2 саму джумлу допиливать - написание компонентов и прочая.
сам как то первым занимался - ипота еще та (если хочешь конфетку сделать), все равно нужен напильник и клей-момент.
А если без js пилить сайтики самому - можно юзать MVC - самая каноничная - рельсы
При этом, для начинающих, как никогда, есть море возможностей:
- знать, по сути, нужно очень мало. Ж.скрипт "фреймвокри" по сравению с другими фреймворками (или даже просто стандартными библиотеками языка) ничтожно маленькие. Тот же Бикбон - весь "фреймворк" - это один файл на 1300 строк. Энгуляр чуть по-больше, ну, может раза в три-четыре. Тот же ж.квери, андерскор и реквайр - они все, в традиционном понимании не фреймворки, а просто скромный набор утилитных функций.
- хороших профессионалов в этой области нет. Что хорошо для начинающего тем, что мало конкуренции, но плохо тем, что в целом занятие это восновном презираемо :)
Что до Питона. Ну, раньше ответ был стандартным: Джанго, а теперь, поскольку, как уже говорилось выше, клиент получил больше прав, то Торнадо, или Твистед. Т.е. отказ от генерации ХТМЛя на сервере, работа через сервисы с использованием ХМЛ / ЯСОН. Даже роутинг сегодня, восновном, задача ж.скрипта. Т.е. сервер по адресу ввв.мойсайт.ру/представление/*/*/*/* отдает один и тот же ХТМЛ с, например, Бикбон раутером, который уже разруливает дальше навигацию по сайту, не вмешивая в это сервер.
Есть некоторые интересные перспективы для начинающих. Например, несмотря на стада ж.скрипт программистов, ни один из них не знает как работать с канвасом, ну и боже упаси от ГЛ. С другой стороны люди пытаются портировать, или писать новые игрушки для мобильников, работающие в обход сторов.
Собственно вся суть. +1
У нас есть JIT.
джаваджун