Насколько я знаю, в Британии как раз вообще все происходит через агентства. Что несколько затрудняет поиск с определенной стороны.
>Нужно понимать, что жить в Лондоне и побывать как турист это сильно разные вещи.
Ну, тут есть несколько аспектов:
— да, в целом это правда, хотя бы потому, что съем квартиры и отель на две недели — вещи уже сильно разные
— из моих знакомых, которые уехали именно в Лондон, кажется только один человек сейчас в Нью Джерси, остальные там же — хотя многие переехали в пригороды
— я знаю людей, которым там просто не понравилось как туристам.
Т.е. в моем круге знакомств — никто не вернулся, и всем нравится.
Ну, не знаю, вы видимо не застали, как было раньше?
Лет пять назад Tier 2 выглядела примерно так, как в Канаде и Австралии: вы набираете баллы: за язык (IELTS нужно сдавать минимум на 7, а лучше больше), за опыт, за возраст, за образование, и подаете документы. Плюс некоторая сумма на счету необходима. Если набрали уровень — с некоторой вероятностью получаете визу, без привязки к работодателю. Дальше въезжаете в страну, и ищете работу где хотите.
А то что есть сейчас… чуть более мелкие фирмы, чем google, вообще не связываются с Tier 2, насколько я знаю. И если вы не хотите работать на google и facebook или не подходите по профилю для microsoft (ну скажем как я), то у вас выбор невелик.
А так бы я с радостью в Лондон, мне там очень нравится.
А какая информация вам нужна? Если говорить упрощенно, то с Британией сейчас все умеренно плохо.
Нормальный прямой путь получения визы закрылся лет пять назад. Сейчас вы можете поехать поработать (например Люксофт достаточно регулярно ищет IT для работы в Лондоне, на Дойче Банк, скажем), на несколько лет. Есть вариант выехать, будучи сотрудником международной компании, имеющей офисы в России и Британии (т.е. трансфер внутри компании).
Вы не будете иметь статус, пригодный для получения ПМЖ, в обоих случаях. Это даст вам только лишь возможность работать в Лондоне, и искать новую работу прямо там. Таких компаний немало, но требования к квалификации во всех случаях высокие.
Я вовсе не претендую на роль специалиста в этой области. Это было скорее пожелание — если уж автор берется писать такую статью, то хоть какие-то данные об уровне зарплат, цен (скажем, Норвегия, насколько я знаю, страна дорогая) и налогов в ней хотелось бы видеть. Не по ссылкам, а в самом тексте. Хотя может кто в комментариях напишет.
Я вот тоже не понял. Сам правда бывал там давно, в 2009, и тогда местная компания CGI была одной из самых крупных известных мне подобных консалтинговых компаний подобного рода. А сейчас кажется даже выросла (65 тыс сотрудников — это вам не шутки, Сбербанк всего в пять раз больше, а Дойче сравним по размеру — при этом банки оба состоят далеко не из IT).
Из минусов Канады назвал бы огромные налоги. Кстати в самой статье почему-то об этом ничего нет — все только в виде ссылок.
Я возможно вас огорчу, но все системы ущербны в этом месте. Если вы дали драйверу доступ к железу — то вы дали ему доступ всюду. Просто потому что существующие железные архитектуры так устроены. Ну ладно — я верю, что есть другие… где все лучше, но все ширпотребные — именно такие.
Да, если на QNX иначе — это это лишь показатель того, что платформа замкнута внутри себя, и устройств, которым нужны драйвера, пренебрежимо мало. Потому что эта проблема — она проблема качества кода, а ему не с чего вдруг самому по себе улучшаться.
Ну, минусов-то тут не за что. Нормальный вопрос, на нормальную (хотя и далеко не новую тему).
Попробую дать свой ответ.
Те кто думает, будто манипулирование коллекциями в таком стиле легче читается, как минимум лукавят. Для кого-то может и легче, но это дело субъективное. Вопросу тут не в легкости. Дело в другом — такой функциональный стиль удобнее компонуется, потому что по сути это функции, которые можно объединять в формулы, спокойно параллелить вычисления (если данные имутабельны и нет побочных эффектов), причем правильность компоновки в значительной степени за нас проверит компилятор.
>Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
Вот это в сущности и есть цель. Чтобы можно было надежно разбивать и компоновать обратно, а части были максимально повторно используемыми.
Ну, кстати Activity — не самый худший вариант. Я бы сказал, что тут имеет место оптимальное разделение обязанностей между движком BPM, и всем остальным (UI, интеграциями, версионированием проекта). В том же случае IBM BPM это например не так. Коммит-логов в нормальном виде там кстати тоже нет (((
В базе данных роль файлов играют схемы и таблицы. Смещения и адреса лежат ниже уровня, доступного пользователю. Так что разницы в общем почти никакой и нет.
Вот смотрите — вы нарисовали красивую картинку «Запрос на предоставление отпуска». Выглядит неплохо, если забыть на время, что это — код. И понять можно. А теперь представьте себе процесс, где диаграмм штук скажем 50 (а это не самый крупный, какой я видел и делал), и каждая из них содержит штук 20 и более элементов. И вы допустим разработчик, и пошли вы в отпуск. Все было хорошо, до тех пор, пока вы не вернулись, и не увидели, что процесс кто-то поменял.
Вот у IBM в этом случае все фигово до безобразия. Диффа нет, merge тоже нет.
Расскажите, что у вас? Есть ли версионирование процессов, можно ли сделать ветку, можно ли сравнить, что было неделю назад с тем что сейчас, можно ли сделать merge?
Вообще-то в тех реальных «адски сложных» бизнес процессах, которые я делал лично и видел, часть BPM была где-то процентов 10 от силы. Ну может иногда 30. А остальные 70 как раз составляли логика UI, и работа с разного рода интеграциями. Поэтому насчет «дешевле» у меня как раз масса вопросов. По той простой причине, что программировать в виде диаграмм в BPM — это ужасно. По сравнению с нормальным процессом разработки на нормальных инструментах — это как в каменный век вернуться.
Видите ли, я не знаю, какие там BPMS вы изучали, а я три с лишним года проработал на IBM BPM. И там можно не просто писать запросы — там полноценный язык программирования, на выбор — либо javascript (Mozilla Rhino) либо чуть посложнее — Java. И формы там допиливаются до любого состояния — с лукапами, с rest запросами, направо и налево. И SQL-запросы пишутся какие угодно, к любой базе. Только все равно получается паршиво.
В принципе, можно интегрироваться с чем угодно. Но только в принципе.
Проблема в том, что как только вы начали писать такой код — вашему процессу как раз и будут опаньки, потому что глядя на диаграмму вы больше ничего уже не понимаете. Вы не видите кода, вы не знаете, что он делает, откуда берет и куда кладет данные. Диаграмма больше не отражает почти ничего. И самый лучший, по моему опыту, способ интегрироваться с каким-либо UI, если он вам нужен — это не делать его в BPM системе вообще. Делать где угодно, в каком угодно виде. На любом инструменте.
Ну, про удалиться и додумать дома — это ведь тоже не я придумал. Я лишь говорю, что люди разные, а время интервью ограничено. Да, возможности проверить напрямую нет. Но и делать из этого сразу выводы рановато.
Вы что-то себе додумали из моего ответа, я такого не говорил. Я лишь сказал, что если у человека не возникли прямо сейчас уточняющие вопросы — это ровным счетом ничего пока не значит. Вот если они не возникли вообще — да, это плохо.
Прежде чем куда-то переходить, нужно для начала продемонстрировать, что семантический дифф реально удобнее обычного, а этого пока не видать. Даже для простого в целом xml я не видел реально работающей технологии. При этом совершенно понятно, что работать с AST внутри кода намного удобнее, чем с текстом. И скажем рефакторинг вряд ли кто-то делает в здравом уме на тексте. Но с показом человеку все хуже.
Общаться со сложным заказчиком и формулировать уточняющие вопросы на ходу прямо в процессе разговора — это все равно две разные вещи. Иногда полезно подумать, прежде чем уточнять.
Мы говорим про код, который не являлся бы текстом. Вон чуть выше коммент от Portnov, с которым я вполне согласен — все известные мне попытки уйти от текстового представления практически сводятся примерно к перечисленным, и все они очень плохи на практике. В том числе потому, что практически работающего диффа нигде нет. То что вы показали, хотя бы для java, выглядит неплохо, но почему-то в реальной жизни все что встречается — это структурный поиск/замена у IDEA.
На самом деле у меня есть подозрение, почему это так. Текст это одномерная структура. Как только мы уходим от одномерности к многомерности, аналогичные алгоритмы на дереве или графе сразу становятся значительно более дорогими вычислительно. И значительно более сложными для понимания. Что косвенно подтверждается комментарием к 8 ответу по вашей ссылке — сложность O(n^2) это ни в какие ворота обычно.
>Нужно понимать, что жить в Лондоне и побывать как турист это сильно разные вещи.
Ну, тут есть несколько аспектов:
— да, в целом это правда, хотя бы потому, что съем квартиры и отель на две недели — вещи уже сильно разные
— из моих знакомых, которые уехали именно в Лондон, кажется только один человек сейчас в Нью Джерси, остальные там же — хотя многие переехали в пригороды
— я знаю людей, которым там просто не понравилось как туристам.
Т.е. в моем круге знакомств — никто не вернулся, и всем нравится.
Лет пять назад Tier 2 выглядела примерно так, как в Канаде и Австралии: вы набираете баллы: за язык (IELTS нужно сдавать минимум на 7, а лучше больше), за опыт, за возраст, за образование, и подаете документы. Плюс некоторая сумма на счету необходима. Если набрали уровень — с некоторой вероятностью получаете визу, без привязки к работодателю. Дальше въезжаете в страну, и ищете работу где хотите.
А то что есть сейчас… чуть более мелкие фирмы, чем google, вообще не связываются с Tier 2, насколько я знаю. И если вы не хотите работать на google и facebook или не подходите по профилю для microsoft (ну скажем как я), то у вас выбор невелик.
А так бы я с радостью в Лондон, мне там очень нравится.
Нормальный прямой путь получения визы закрылся лет пять назад. Сейчас вы можете поехать поработать (например Люксофт достаточно регулярно ищет IT для работы в Лондоне, на Дойче Банк, скажем), на несколько лет. Есть вариант выехать, будучи сотрудником международной компании, имеющей офисы в России и Британии (т.е. трансфер внутри компании).
Вы не будете иметь статус, пригодный для получения ПМЖ, в обоих случаях. Это даст вам только лишь возможность работать в Лондоне, и искать новую работу прямо там. Таких компаний немало, но требования к квалификации во всех случаях высокие.
Из минусов Канады назвал бы огромные налоги. Кстати в самой статье почему-то об этом ничего нет — все только в виде ссылок.
Да, если на QNX иначе — это это лишь показатель того, что платформа замкнута внутри себя, и устройств, которым нужны драйвера, пренебрежимо мало. Потому что эта проблема — она проблема качества кода, а ему не с чего вдруг самому по себе улучшаться.
Попробую дать свой ответ.
Те кто думает, будто манипулирование коллекциями в таком стиле легче читается, как минимум лукавят. Для кого-то может и легче, но это дело субъективное. Вопросу тут не в легкости. Дело в другом — такой функциональный стиль удобнее компонуется, потому что по сути это функции, которые можно объединять в формулы, спокойно параллелить вычисления (если данные имутабельны и нет побочных эффектов), причем правильность компоновки в значительной степени за нас проверит компилятор.
>Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
Вот это в сущности и есть цель. Чтобы можно было надежно разбивать и компоновать обратно, а части были максимально повторно используемыми.
Вот смотрите — вы нарисовали красивую картинку «Запрос на предоставление отпуска». Выглядит неплохо, если забыть на время, что это — код. И понять можно. А теперь представьте себе процесс, где диаграмм штук скажем 50 (а это не самый крупный, какой я видел и делал), и каждая из них содержит штук 20 и более элементов. И вы допустим разработчик, и пошли вы в отпуск. Все было хорошо, до тех пор, пока вы не вернулись, и не увидели, что процесс кто-то поменял.
Вот у IBM в этом случае все фигово до безобразия. Диффа нет, merge тоже нет.
Расскажите, что у вас? Есть ли версионирование процессов, можно ли сделать ветку, можно ли сравнить, что было неделю назад с тем что сейчас, можно ли сделать merge?
В принципе, можно интегрироваться с чем угодно. Но только в принципе.
Проблема в том, что как только вы начали писать такой код — вашему процессу как раз и будут опаньки, потому что глядя на диаграмму вы больше ничего уже не понимаете. Вы не видите кода, вы не знаете, что он делает, откуда берет и куда кладет данные. Диаграмма больше не отражает почти ничего. И самый лучший, по моему опыту, способ интегрироваться с каким-либо UI, если он вам нужен — это не делать его в BPM системе вообще. Делать где угодно, в каком угодно виде. На любом инструменте.
На самом деле у меня есть подозрение, почему это так. Текст это одномерная структура. Как только мы уходим от одномерности к многомерности, аналогичные алгоритмы на дереве или графе сразу становятся значительно более дорогими вычислительно. И значительно более сложными для понимания. Что косвенно подтверждается комментарием к 8 ответу по вашей ссылке — сложность O(n^2) это ни в какие ворота обычно.