Матвей Мамонов: если не постучаться, то точно ничего не произойдет. Никто мыслей читать не умеет, поэтому пока не обозначишь свой интерес, о нем никто не узнает. Поэтому да - надо стучаться туда, куда хочется войти. Разумеется, не все двери сразу открываются, но четкая цель и настойчивость горы сворачивают. :) Когда я, будучи студентом-геологом, искал свою первую айтишную работу, хождение по собеседованием на пару месяцев, стало моей работой :) Помнится было до 2-3 собеседований в день в разных компаниях. В итоге нашлась компания, которая дала мне шанс поработать джуниором. Дальше пошло уже легче. Хотя по началу приходилось в свое личное время грызть гранит программистских мудростей, чтобы справляться :D
Владимир Солдатов: пытаться заставить "внешние системы" работать иначе - обычно такая-же пустая затея, как рефакторинг автогенерируемого кода. API которое поставлется внешними системами как продукт / сервис обычно соповождается документацией. В ней должны быть указаны ограничения на время отклика, чтобы пользователи этого API могли правильно обработать timeout.
Вы можете попробовать сподвигнуть разработчиков SAP что-то предпринять, если найдете эти лимиты, потом сделаете запрос, который будет отрабатывать дольше и затем это отправите как баг. В результате будет одно из трех:
1) Поправят документацию
2) Подскажут как оптимизировать ваш запрос, чтобы уложиться в лимиты
3) Предпримут какую-то оптимизацию на своей стороне, что может вылиться в целом в ускорение системы
В любом случае все это будет длиться муторно и долго и скорей всего кончится, когда вы уже смените проект или место работы.
Если есть контакты разработчиков - спросите их, как можно ускорить отклик от SAP. Иногда даже достаточно проапгрейдить мощности сервера. Часто корпоративка крутится на чахлых серверах а то и вовсе - кастрированных виртуалках. В общем можно попробовать поискать bottle neck (узкое место, слабое звено).
В целом нужно уметь делать свою работу хорошо, не пытаясь сделать идеальным весь мир, Так как это пустая трата времени. А умение работать с неидеальным окружением корректно - ценный профессиональный навык. Не стоит сражаться с ветряными мельницами. Успехов!
Если в backend организовать как Web API, можно frontend делать хоть HTML страницей, лежащей в dropbox-e, и общающейся с backend-ом посредством Ajax запросов. Web API - довольно удобная штука для серверной части, имеет массу готовых элегантных решений для типовых задач на стороне сервера.
ivorobioff: попытки читерства встречаются. чаще правда, когда кандидат пытается найти ответ онлайн вместо того чтобы написать десяток строк кода самостоятельно. если передумаете позже - схема действий у вас имеется. если нет, ну значит работа у нас не то, что вам подходит. это тоже нормально. все разные. каждому - свое.
ivorobioff: смотреть надо чтобы исключить ситуации, когда кодилити за кандидата проходит другой человек. Пробуйте еще. Если не проходите какой-то этап, можно пробовать снова (после подготовки) по этой схеме https://www.quora.com/If-I-fail-interview-on-Topta...
- английский - это просто необходимость для работы.
- кодилити - это отсев ленивых (набрать проходной балл там несложно даже для тех, кто не алгоритмист - например я прошел когда-то :) )
- интервью - для провеврки ваших знаний в целом
- тестовый проект - посмотреть как вы умеет работать на проектах, которые обычно называют "реальными"
strongmonkey: ах ну да - это ж CLR хранимка. Тогда смущает отсутствие атрибута [Microsoft.SqlServer.Server.SqlProcedure] и имена параметров в хранимке и в методе разные.
Дмитрий Купчинский: по фронтенду (клиентская часть) тут два подхода (устаривающий ASP.NET WebForms не рассматриваю, смысла кому-то разбираться в нем не вижу).
1) использовать ASP.NET MVC - это по сути шаблоны HTML (файлы .cshtml) страниц где вы можете писать вставки серверного кода через так называемый Razor. Подобным образом в PHP стэке вы можете внедрять динамическую HTML разметку в результирующую HTML страницу, которая отдается в браузер.
2) можно вынести всю серверную логику (получение / передачу данных) за API. API в дотнет стэке пишется с использованием фреймворка Web API. Дальше вы можете в качесте фронтенда использовать хоть простые HTML страницы, которые через JS будут с помощью AJAX запросов взаимодействовать с вашим API. ну а динамическая страница будет собираться уже на клиенте с помощью например одного из JS фреймворков, вроде Angular, Knockout и т.п. Таким образом вы можете вебсайт вообще сделать SPA в виде одного HTML файла. Однако обычно мы хотим иметь разные страницы и соответствующие им URLs вроде mysite.com/about mysite.com/goods/123456 и т.п. Тут удобно все таки оставить использование ASP.NET MVC но не использовать Razor вставки. Просто работать также как с голым HTML. ASP.NET MVC в этом случае удобен тем что позволяет управлять роутингом (адреса страниц), общим мастер шаблоном для всех страниц и всякой прочей вспомогательной ерундой вроде обработки ошибок, и тп. В общем - в этом случае от MVC будет использваться управление инфраструктурой веб приложения, но не будет испольоваться МVС-шный рендеринг.
Lancer9: тогда нужны будут инвестиции с вашей стороны приличные на первые пару лет развития проекта. Я как фрилнасер не понял - зачем мне может быть это нужно. Гарантировать что работа для меня всегда будет вы не сможете в любом случае. Никто не может :) Желаю успехов! Надеюсь, у вас все получится.
Роман: да, конечно, много всего есть. перечислять все варианты смысла нет. тут вопрос стоит в том, чтобы помочь человеку сориентироваться в целом, что к чему. я уверен можно еще с десяток другой наковырять всяких фреймворков для дотнета.
Если вам не хочется это делать - не делайте. Если вам хочется, но не бесплатно - скажие клиенту, что вам все нравится в работе. кроме отсутствия оплаты и это критичный момент. Если вам нравится работать над проектом бесплатно - работайте в удовольствие. В общем, полная свобода действий как, впрочем, всегда в любой ситуации.
Lancer9 а вы какую цель преследуете? Если заработать денег, думаю, ничего не выйдет. Рынок действительно заполнен. Для того чтобы бодаться с конкурентами, нужны серьезные инвестиции. Если брать отечественный рынок в этой сфере - то имеющиеся площадки ничего не гарантируют и предназначены для работы вчерную в основном. Если делать схему которая всех заставить на площадке работать в делую - пропадет смысл зачем на отечественном рынке нанимают фрилансера - съэкономить. Проще будет нанаять в штат человека, если за него налоги платить все равно. Ну и как-то не слишком популярно работать вбелую у нас. Те кто занимается фрилансом всерьез - либо работают на западный рынках и тогда им часто (да и то не всем) нужно работать в белую, либо работаю в домашнем регионе, но тогд аобычно - с небольшим количеством давних клиентов, с которыми были многократные заказы и выработалсь схема сотрудничества. Если ставить себя на роль клиента и на роль фрилансера - непонятно зачем пользоваться системой. По сути у фриланс бирж задача - это просто доска объявлений КУПЛЮ/ПРОДАМ, если они деньги не пропускают через себя и не предоставляют какие-то другие услуги. Почему в вашем случае обе стороны процесса должны быть согласны на вашу комиссию?
