belozerow: не похоже это на Toptal - у нас все работает не так - blog.payoneer.com/%D1%83%D0%B4%D0%B0%D0%BB%D0%B5%D...
В апворке пытаются создать какие-то рафинированные группы разработчиков из тех кто есть на бирже, но как-то не с той стороны мне кажется это все затеяли...
Примерно из расчета от 40 до 75 евро за сутки пребывания на территории шенгена скажем на человека. Сумма может варьироваться от страны, через которую виз делаете, и срока пребывания.
Дмитрий Ковальский: тогда параметр строкой, а в конроллере что-то типа
dynamic json = JObject.Parse(yourJsonObject);
ну и дальше уже работать с его полями
обратить внимание советую на последний третий - на мой взгляд вышло довольно удобно. его можно чуть модифицировать - чтобы вместо exception возвращать скажем null, если указанный в виде массива имен свойств путь в JSON объекте не существует.
vasIvas: ерунда не ерунда - оценивать это "неокрепшим умам". А отрицатние моей позиции у вас, возможно, "Потому что они, опытные программисты не смогли разобраться и понять до конца что" я собственно говорю :) Не кипятитесь. Ради эксперимента, перечитайте без предвзятого мнения, как будто у вас собственного просто нет. Иногда это помогает взглянуть на вопрос шире или в новом ракурсе. Я же не советую людям игнорировать паттерны, как ненужное заблуждение. Я ответил на вопрос топика. И уж в том как я освоил паттерны - лучше меня вряд ли кто-то может рассказать :)
vasIvas: может и не программист :) смотря что вкладываете в термин :)
В любом случае - людей и мнений много. Я поделился своим, к которому пришел вдумчиво и, надеюсь, оно поможет кому-нибудь вместо заучивания догм, использовать собственный мысленный процесс, не слишком бездумно полагаясь на быстрые рецепты очередной "запеканки", коих даже в нашей индустрии уже было немало. Не хочу преумалять важность понимания шаблонов и прочих лучших практик, но и преувеличивать - тоже. Во всем есть плюсы и минусы. Важно соблюсти баланс разумного использования различных подходов, исходя из конкретной ситуации и имеющегося набора критериев.
Андрей Дегтярук: согласен - про паттерны много слов. Недавно с подобным ажиотажем вокруг BigData появилась в сети классная шутка "Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it..."
Про Design Patterns - можно сказать тоже самое на мой взгляд :)
vasIvas: шансов "проплясять 10 лет в кардабалете" и не выяснить терминологию нет. :) Наша индустрия такова, что в любой день с утра можно получить задачу, которой в глаза раньше не видел. Более того, такая ситуация - скрей правило, чем исключение :) И перед тем как ее решать, понадобится разобраться в вопросе. Думаю, эта знакомо всем, кто программирует что либо хоть сколько-нибудь продолжительное время. Поэтому не прочесть что-то о паттернах за это время вряд ли что-то получится.
Я кстати знаком со специалистами, которые вполне умело и к месте оперииложенируют "мостами/бриджами с синглтонами", но тем не менее изложить внятно мысль затрудняются. То о чем вы говорите - просто косноязычие, я думаю :) Любую модель (в том числе и приложение - как модель процесса) всегда удобней и понятней описывать с помощью родной для предметной области терминологии. Излишнее нагромождение абстрактными техническими терминами - затрудняет коммуникацию в проекте с теми, кто не технический специалист. А времена когда активно использовался Waterfal - модель процесса разработки ПО, когда на каждом этапе из бизнес требований сначала делали бизнес спецификации, из них - технические и так все постепенно переводилось для каждой группы в проекте на понятный ей язык - эти времени давно в прошлом. Сейчас реальность вынуждает всех следовать какой-то из вариаций Agile процесса, в котором всего этого нет и чтобы дело как-то двигалось с мертвой точки - всем в проекте удобней общаться единым, понятным всем языком.
Кроме того, в современной индустрии разработки ПО уверенно движется прочь от монолитных приложений, где компоненты это единицы выделенные разработчиками логически и физически, но это все равно что-то достаточно примитивное - кучка файлов, лежащих рядом друг с другом. Сейчас большинство более или менее серьезных приложений - это часто гибридные системы, взаимодействующие сдруг с другом и часто реализованные разными компаниями и командами с использованием широчайшего спектра технологических стэков. Так что шаблоны необходимо как минимум серьезно переосмыслить в плане их применимости к новым реалиям. Появились новые подходы, новые шаблоны, через полгода они могут стать анти-паттернами и т.п.
Последняя мой посыл заключался скорее в том, как научиться строить правильно в плане архитектуры. Цель ведь - в этом, а не в сдаче какого-то теста по теме шаблоны проектирования :)
Тогда грузить данные в переменную (то есть не ускорится - так как загрузка в начале полная) и потом брать частями из нее (чтобы показывать на UI в редиме подгрузки, снижая нагрузку на рендеринг самого UI). Hапишите функцию чтобы брать из переменной частями и используйте ее когда надо показать очередную порцию данных пользователю
