Форумчане в рунете всегда злые на язык. Это сформировавшийся факт. В большинстве англоязычных форумов такой агрессии, а то и просто неприкрытого хамства нет. Не знаю уж почему так у нас принято. Относительно фидбека на статью, многие просто не доросли и не понимают, о чем сказал Дмитрий. Остальные прицепились к незначительным мелочам, либо прочли по диагонали, либо действительо не согласны (хотя я не заметил толковых аргументов против — все попытки это сделать опирались на другие критерии оценки ситуации, не те о которых говорит Дмитрий). В любом случае — любое мнение имеет право на существование. Я полагаю, к примеру, что тем кто имеет другое мнение достаточно изложить его в соей статье или интервью (если его у них кто-то скажем захочет взять, конечно). :)
Когда меня спрашивают, как по быстрому подтянуть английский для работы, я советую так:
«Учите английский слушая подкасты и смотря видео материалы по вашему технологическому стеку. Много общайтесь на технических англоязычных форумах по своей теме. Если есть возможность вести рабочую переписку с иностранцами по работе — ведите ее. Впитывайте те конструкции, которые используют они. Применяйте их активно в ответ. Если сталкиваетесь с технической документацией (спецификации, документация по проекту), читайте все. В качестве полировки знаний — используйте один из сайтов для изучения языка. Их много и там вам освежат основы грамматики. Все это вместе обеспечит вас необходимым минимумом английского, необходимого вам для работы.»
Относительно того, как подучить язык быстро. Я бы советовал просто уделять обучению не менее 15 минут в день. Важно — КАЖДЫЙ ДЕНЬ не пропуская. Если вдруг будет желание и возможность заниматься дольше чем 15 минут — прекрасно. Но никак не меньше. Пусть это будет что-то простое и на бегу (аудиокурс какой-то в машине/ транспорте по пути домой), но главное не пропускать. Если позволяет время — очень поможет ходить на занятия по старинке к преподавателю вдобавок к описанному выше. Причем тут даже не требуется посещать N раз в неделю — одного раза в неделю (при условии самостоятельного ежедневного самообучения) будет достаточно. 4 раза в месяц — это немного и поэтому гораздо эффективней будет заниматься в одиночку или хотя бы в малой группе (до 2-3 человек). Можно рассмотреть вариант со скайп преподавателем (это удобно и недорого). В больших групповых занятиях толку от обучения мало. Можно потратить годы.
Относительно других языков. Мой личный опыт такого обучения заключается в изучении немецкого языка. Его я учил с нуля, не сильно торопясь. Правда второй иностранный идет быстрее. За год я довел его до простого но сполне сносного разговорного уровня. Проверял в Германии потом :) Для общения на улице мне хватает. Думаю можно было обучиться и быстрее раза в 2-3, если бы использовал его в ежедневной работе. Но я учил его просто потому что мне он очень нравится. Мне понравился для немецкого аудиокурс по методу Мишеля Томаса/ Я слушал этот курс немецкого на английском, и мне кажется, что так даже проще.
На мой взгляд, если брать по РФ средняя зарплата некоего «усредненного абстрактного программиста» — 40-50К рублей в месяц.
В крупных городах — это сдвигается в сторону 100К. В Москве, Питере — чуть выше (расходы на быт там тоже выше). Дальше в случае наличия б0льшего опыта и/или каких-то востребованных навыков — к 150K. В редких случая (с компаниях, которые имеют возможность, не хотят иметь большую текучку и заинтересованы оптыных уже людей оставлять у себя надолго) — накидывается процентов 15-30% сверх реального рынка. В этом случае сотрудникам потом просто не найти условий лучше. И все счастливы вроде бы — и работодатель, и разработчик. Если конечно последний не заскучает и не начнет придумывать свои стартапы и прочую ерунду. Тут только надеяться, что у работодателя хватит интереностей, чтобы занять беспокойный ум сотрудника с пользой для себя.
Я говорю не о том, что это неподъемная задача. А о том, что это — дополнительные активности, которые будут отъедать ваш временной ресурс. И по началу — весьма с хорошим аппетитом. Предпринимательствуя, кроме этой смежной админирстративной деятельности, нужно еще заниматься основной, приносящей собственно доход. С банками вообще говоря, желательно ИП иметь отдельный счет от счетов физлица, чтобы потом не путаться в отчетности с каких поступлений надо платить налог, а какие — это «бабушка прислала».
В работе на себя (и в одиночку, и в режиме образования мелких компаний под проект/ты) тоже есть сложности). Во всем есть как плюсы так и минусы. Но если есть желание попробовать и готовность принять сопутствующие риски, это, конечно, нужно сделать. Но еще раз — сам факт того, что вы стали работать на себя не гарантирует, что у вас будут заказы, и если будут, что это будет выгодно… Кроме того, в самостоятельной деятельности возникает большое количество дополнительные дел, с которыми вы ранее не сталкивались. Всякого рода административные вопросы, взаимодействие с контролирующими органами, банками, арендодателями и прочая суета. Всем желающим перестать работать «на дядю» посоветовал бы примерно прикинуть, на что уходят ресурсы у этого «дяди» кроме видимой вам со стороны.
Если нет continuous integration и тестовое окружение не доступно на каждый билд — это, конечно, сложнее. В остальном — как раз вызовом API программно через вебклиента вы по сути лучше проверяете взаимодействие с вашим приложением извне — более честно. Ведь методы контроллера никто напрямую не вызывает как библиотечные. Соответственно, чтобы задействовать все праоверки доступа, маршрутизацию и тп — как раз и удобно подергать контроллер через URL.
Плюсов в данном подходе на мой взгляд больше, чем минусов в случае сложностей либо с непокрытыми вовсе контроллерами, либо с войной против зависисмостей, даже подмена которых для тестовых целей точно не всегда обеспечит вас уверенностью, что все что вы хотите проверить, действительно отработает в рабочем окружении.
Razaz — в качестве альтернативы юнит тестам в этой ситуации, чтобы отловить указанные моменты в работе контроллера Web API или MVC приложения можно делать в тестах запросы через HttpClient или подобными способами — http://www.diogonunes.com/blog/webclient-vs-httpclient-vs-httpwebrequest/
Запускается в вместе юнит тестами, но по сути являются уже интеграциоными. Выглядит и работает хорошо, сигнализирует о проблеме — тоже. В response будет все, что вы ожидаете или наоборот.
Думаю, с помощью таких вот интеграционных тестов на контроллеры (покрыващих вопросы контента, маршрутизации, и тп) — вполне можно смириться с непокрытием их обычными юнит тестами. Особенно если (как справедливо заметил qw1 ) логику держать все-таки в сервисах и юнит-тестировать их.
Вполне все удобно получается. И зависимости контроллера не помешают. Для интерграционных тестов достаточно иметь поднятое окружение для тестирования. URL прописать в конфиг его для тест проекта. Локально чтобы на локальной машине гонялись, На билд сервере — на тестовом окружении.
Работа в стандартном варианте в принципе приносит минимально допустимый доход, с которым человек готов трудиться. В любой профессии. Тут как всегда работает рынок с его балансом спроса и предложения. Если никто не захочет триудиться за сумму X, работодатели будут вынуждены либо поднять оплату на до X+Z, либо (если это окажется нерентабельным в новых условиях) сместить свои коммерческие интересы на другую область бизнеса.
С нефтью, к примеру, также обстоит — сначала добывают запасы более легких категорий по извлечению. Когда они подходят к концу (с учетом усовершенствования технологий добычи — снижения стоимости ее, и увеличении спроса — повышении цены) — можно заняться и теми категориями запасов, которые до этого добывать было не выгодно.
Разве есть что-то лучше нас? :) Подробнее про нас тут «Удаленная работа в Toptal для программистов» http://blog.payoneer.com/удаленная-работа-в-toptal-для-программисто/?lang=ru
В том и дело — что бизнес этот свой — это просто модно. Реально — нафиг особо никому не надо, потому что не просто. Вот и возникакет конфликт внутренний — с одной стороны вроде «круто», а с другой стороны — нормальный человек не любит делать то, что ему не нравится. Не надо гнаться за модой ради моды, думается.
Кешируемость в ряде случаев — как раз относится к минусам, откоторых хочется избавиться.
Заимствовать (не дублировать полностью) основной концепт этого подхода и cделать удобную — обладающую необходимыми свойствами и характеристиками (в рамках выбранных критериев) — реализацию API. Я говорю об этом. И о том, что «RESTful webservices» напрасно возвели на пьедестал и холиворно бездумно стараются его придерживаться всегда и везде. Любая концепция хороша к месту.
Утомился я пререкаться. Думаю, продолжать не уже буду. Спасибо за дискуссию.
Да, тоже не надо гнаться. Любая идея, возведенная в абсолют — зло :) Архитектура — это выбранный способ устройства частей приложения и их взаимодействия. Может быть любой. Какой бы она ни была — это будет архитектура. Плохая она или хорошая — можно судить используя выбранные критерии. Поддерживаемость, тестируемость и прочие так нахываемые "-ilities" как раз и являются этими самыми криетриями. Подчеркну еще раз, что оценку архитектуры на «хорошесть» делают именно относительно выбранных криетериев, а не всех имеющихся в природе в принципе. Это важный момент. Выбор тех или или иных критериев обусловлен требованиями к приложению. Которые (обычно) обусловлены бизнес задачами (в случае коммерческого ПО по крайней мере).
Думаю мне удалось донести мысль о том, что стремление соответствовать какому-либо понятию, не имея обусловленной понятными причинами потребности в этом, а просто потому что так «правильно» — это глупость?
На счет самих слов «использовать REST» — не понимаю, зачем вы мне приписываете неясные формулировки, а потом возмущаетесь что я там что-то не так навал и асамозабвенно минусуете мои коментарии. Я четко сказал, что можно заимствовать концепцию («Принципы REST») и избавиться от многих ограничений данного подхода. Ну а что как называть — дело вкуса :) Тут следуется договориться о терминах перед тем как спорить.
REST — это не конкретная технология (реализация), а стиль архитектуры что ли… метод взаимодействия частей распределённого приложения в сети интернет.
При соблюдении (надо сказать довольно расплывчатых требований) та или иная реализвация вашего сервиса может быть с той или иной долей справедливости названа «RESTful» веб сервисом.
Да нет. Я к тому, что глупо гнаться за понятием, когда занимаешься практической работой. Не вижу смысла навешивать ярлыки на технологии, принимать одну их них за священную корову и потом мучаться от ее недостатков в ежедневной работе. Это удел молодых программистов, которые пороху еще не нанюхались и собак съели мало :)
Верно. Это противоестественно для REST. Но речь как раз и идет о том, чтобы не сковывать себя ограничениями REST отвязать свою модель зваимодействия поверх HTTP. POST запрос в плане ограничений самый беспроблемный и имеет массу преимуществ с точки зрения программиста. Использовать его как транспорт для любых типов запросов — удобно. Семантику запроса в этом случае убираем в тело передаваемых JSON данных и используем POST паровоз для отправки наших запросов и получения ответов от сервера.
Принципы REST если они вам удобны и дороги — можно перенести и внутрь ваших сообщений, поджерживая все составляющие REST запроса — метод, ресурс, данные, код возврата и тп. При этом избавившись от душевных мук, когда в проекте рано или поздно все равно придется отступить от RESTful и сделать идеологический хак, потому что иначе не получается из-за ограничений RESTful сервисов :)
Я согласен с автором статьи. Думаю самый хороший вариант с точки зрения разработчика — это уяснить суть RESTful сервисов, понять какие бывают типы запросов, какие из них реально поддерживаются, разобраться в кодах, в целом «подружиться» с каналом передачи протоколом HTTP и т.п. Все это даст понимание технологии и знания как правильно с ней работать. Дальше действительно удобней использовать только POST и с помощью JSON уже формировать удобную для себя структуру пакета сообщений, реализовывая по сути старый добрый request/response подход, который зарекомендовал себя давно и использовался почти во всех системах и технология сетевого взаимодействия. Надо заметить при этом, что в своих сообщениях разработчик может поддерживать принципы REST, введя свои типы сообщений для CRUD операций и поддерживая логику их обработки. HTTP в данном случае будет просто транспортом. Отвязка от канала передачи — это (опятьже согласен с автором) большой плюс.
Согласен. Карьера — это просто то, что должно добавлять сопртивного интереса в рутину. Чтобы были какие-то формальные ачивки :) По большому счету сути происходящего это не меняет.
«Учите английский слушая подкасты и смотря видео материалы по вашему технологическому стеку. Много общайтесь на технических англоязычных форумах по своей теме. Если есть возможность вести рабочую переписку с иностранцами по работе — ведите ее. Впитывайте те конструкции, которые используют они. Применяйте их активно в ответ. Если сталкиваетесь с технической документацией (спецификации, документация по проекту), читайте все. В качестве полировки знаний — используйте один из сайтов для изучения языка. Их много и там вам освежат основы грамматики. Все это вместе обеспечит вас необходимым минимумом английского, необходимого вам для работы.»
Относительно того, как подучить язык быстро. Я бы советовал просто уделять обучению не менее 15 минут в день. Важно — КАЖДЫЙ ДЕНЬ не пропуская. Если вдруг будет желание и возможность заниматься дольше чем 15 минут — прекрасно. Но никак не меньше. Пусть это будет что-то простое и на бегу (аудиокурс какой-то в машине/ транспорте по пути домой), но главное не пропускать. Если позволяет время — очень поможет ходить на занятия по старинке к преподавателю вдобавок к описанному выше. Причем тут даже не требуется посещать N раз в неделю — одного раза в неделю (при условии самостоятельного ежедневного самообучения) будет достаточно. 4 раза в месяц — это немного и поэтому гораздо эффективней будет заниматься в одиночку или хотя бы в малой группе (до 2-3 человек). Можно рассмотреть вариант со скайп преподавателем (это удобно и недорого). В больших групповых занятиях толку от обучения мало. Можно потратить годы.
Относительно других языков. Мой личный опыт такого обучения заключается в изучении немецкого языка. Его я учил с нуля, не сильно торопясь. Правда второй иностранный идет быстрее. За год я довел его до простого но сполне сносного разговорного уровня. Проверял в Германии потом :) Для общения на улице мне хватает. Думаю можно было обучиться и быстрее раза в 2-3, если бы использовал его в ежедневной работе. Но я учил его просто потому что мне он очень нравится. Мне понравился для немецкого аудиокурс по методу Мишеля Томаса/ Я слушал этот курс немецкого на английском, и мне кажется, что так даже проще.
stackoverflow.com/research/developer-survey-2015#work-complang
www.superjob.ru/research/articles/111800/samye-vysokie-zarplaty-v-sfere-it
person-agency.ru/salary-programmist.html
На мой взгляд, если брать по РФ средняя зарплата некоего «усредненного абстрактного программиста» — 40-50К рублей в месяц.
В крупных городах — это сдвигается в сторону 100К. В Москве, Питере — чуть выше (расходы на быт там тоже выше). Дальше в случае наличия б0льшего опыта и/или каких-то востребованных навыков — к 150K. В редких случая (с компаниях, которые имеют возможность, не хотят иметь большую текучку и заинтересованы оптыных уже людей оставлять у себя надолго) — накидывается процентов 15-30% сверх реального рынка. В этом случае сотрудникам потом просто не найти условий лучше. И все счастливы вроде бы — и работодатель, и разработчик. Если конечно последний не заскучает и не начнет придумывать свои стартапы и прочую ерунду. Тут только надеяться, что у работодателя хватит интереностей, чтобы занять беспокойный ум сотрудника с пользой для себя.
Бизнесу содействуют… Лучше бы просто не мешали.
Плюсов в данном подходе на мой взгляд больше, чем минусов в случае сложностей либо с непокрытыми вовсе контроллерами, либо с войной против зависисмостей, даже подмена которых для тестовых целей точно не всегда обеспечит вас уверенностью, что все что вы хотите проверить, действительно отработает в рабочем окружении.
Так не думаете?
Запускается в вместе юнит тестами, но по сути являются уже интеграциоными. Выглядит и работает хорошо, сигнализирует о проблеме — тоже. В response будет все, что вы ожидаете или наоборот.
Думаю, с помощью таких вот интеграционных тестов на контроллеры (покрыващих вопросы контента, маршрутизации, и тп) — вполне можно смириться с непокрытием их обычными юнит тестами. Особенно если (как справедливо заметил qw1 ) логику держать все-таки в сервисах и юнит-тестировать их.
Вполне все удобно получается. И зависимости контроллера не помешают. Для интерграционных тестов достаточно иметь поднятое окружение для тестирования. URL прописать в конфиг его для тест проекта. Локально чтобы на локальной машине гонялись, На билд сервере — на тестовом окружении.
С нефтью, к примеру, также обстоит — сначала добывают запасы более легких категорий по извлечению. Когда они подходят к концу (с учетом усовершенствования технологий добычи — снижения стоимости ее, и увеличении спроса — повышении цены) — можно заняться и теми категориями запасов, которые до этого добывать было не выгодно.
Примерные зарплаты по странам и должностям — http://www.payscale.com/rccountries.aspx
Примерные расходы на жизнь по миру — http://www.numbeo.com/cost-of-living/
Кому интересно прицениться — почситайте, что где остается.
Заимствовать (не дублировать полностью) основной концепт этого подхода и cделать удобную — обладающую необходимыми свойствами и характеристиками (в рамках выбранных критериев) — реализацию API. Я говорю об этом. И о том, что «RESTful webservices» напрасно возвели на пьедестал и холиворно бездумно стараются его придерживаться всегда и везде. Любая концепция хороша к месту.
Утомился я пререкаться. Думаю, продолжать не уже буду. Спасибо за дискуссию.
Думаю мне удалось донести мысль о том, что стремление соответствовать какому-либо понятию, не имея обусловленной понятными причинами потребности в этом, а просто потому что так «правильно» — это глупость?
На счет самих слов «использовать REST» — не понимаю, зачем вы мне приписываете неясные формулировки, а потом возмущаетесь что я там что-то не так навал и асамозабвенно минусуете мои коментарии. Я четко сказал, что можно заимствовать концепцию («Принципы REST») и избавиться от многих ограничений данного подхода. Ну а что как называть — дело вкуса :) Тут следуется договориться о терминах перед тем как спорить.
REST — это не конкретная технология (реализация), а стиль архитектуры что ли… метод взаимодействия частей распределённого приложения в сети интернет.
При соблюдении (надо сказать довольно расплывчатых требований) та или иная реализвация вашего сервиса может быть с той или иной долей справедливости названа «RESTful» веб сервисом.
Принципы REST если они вам удобны и дороги — можно перенести и внутрь ваших сообщений, поджерживая все составляющие REST запроса — метод, ресурс, данные, код возврата и тп. При этом избавившись от душевных мук, когда в проекте рано или поздно все равно придется отступить от RESTful и сделать идеологический хак, потому что иначе не получается из-за ограничений RESTful сервисов :)