Ну с 7 зоны если перется, то и ойстер будет дороже. В целом данные по ЗП в Лондоне ваши подтверждаю (как в других городах UK не знаю). Могу только дополнить, что многие первое время 50К получают и не жужжат — и увы это чистое правда. Многие спрашивают а как жить? Да вот так и живут, разные обстоятельства — кто-то в теске питается, или ланч с собой, или с мамкой живут на их квартире — пока доход не позволяет.

Есть еще «компьюторщик» — это типа «тожепрограммиста», обычно частое слово и используется в лексиконе «управленческой элиты». А начет терминов, я бы не заморачивался так, ведь ответы на поверхности и без сокрального смысла — «инженер», значит есть высшее техническое образование, с «кодером» тоже все понятно — это «макака» которую если обучить Visual Basic можно отправить на Марс (старая шутка про Майкрософт), девелопер — это разработчик который работает с иностранным клиентом, а разрабочик — его калька с английского, относительно новое слово, в 90-х я не припомню чтоб программистов называли разрабочиками. Впервые я услышал в 2000х, даже не помню кто его изобрел ) ПрограммистЪ — это самое старое из всех перечисленных слов (исключая инженера), инженер-программист — тоже что и инженер с дипломов в CS или CE

Oracle в 90-х начало 2000-х это тихий ад для разработчика. Код был не просто ад, а адищще, принятый TDD был скорее закономерностью, ибо ранние версии Oracle были написаны на Pascal (кстати, этим объяснялась их любовь к «Борману/Borland»). Кроме того код надо было портировать на C — ибо без C не было бы связки с тогда еще новым языком Java (на это решение повлияло кстати тот факт, что Ларри как раз в то время возглавлял и Apple, а когда началось портирование на C++, с тогда еще только появившимся STL — начался трешаковый ад — типа первых попыток реализовать OCCI дав волну различных велосипедов лишь бы уменьшить геморрой от ObjC и OCI).
Многие тут спорят TDD в Оракле или не TDD )) Народ, могу успокоить в версии Oracle многие вещи имеют «иное» понимание — от их реализации STL (особенно под UltraSparc лол) до их понимания паттернов проектирования в те года (особенно запомнилась с тех времен реализация PImpl).
Мое мнение Oracle существует только потому, что Ларри подмазал везде и у ЦРУ и IBM, и Apple, и Sun (когда он еще существовал) он с кем надо давно договорился — просто посмотрите его биографию и станет понятно — почему этот монстр до сих продается (только не надо мне про масштабируемость решений от Оракл) И да, легко верю автору, что хуже кода базы Оракл нет ничего в мире))

Можно делать снимок root view controller/root activity принадлежащее им, либо дочернее от вышеназванного. Объект push notification/alert таковым не является.

Нет, «оно» делает снимок root view controller/root activity принадлежащее им, либо дочернее от вышеназванного. Объект push notification/alert таковым не является

Актуализирую информацию и выскажу мнение на 06.2018. На основе собственного опыта и изучения рынка решений проблем распространения:
1. TestFlight + Google Play — для обоих решений требуется… никаких усилий, от слова совсем. Оба решения есть часть консоли разработчика Apple и Google. Уже будут и отчеты о крашах и распространение без «серых» сертификатов, вообще все «легально» и в «белую». Недостаток лишь один — недоступно распространение на Amazon и Samsung маркетплейсы (короче только Google).
2. HockeyApp — в принципе понравился тем что довольно легко интегрируем и даже без CocoaPods (я с большой настороженностью отношусь к неродным по отношению к продукту непрозрачным заскриптованным активностям в предкомпайл стадии).

Fabric в принципе это из мира единорогов ибо натягивается на любой нетривиальный сценарий сборки (иными словами любой что за пределами понимания разработчиков Fabric — т.е. все то, что не является ни xCode ни Android Studio/Eclipse) Так вот какие-то сценарии через CI с разными фокус группами распространения — такой геморрой. И если даже получится, то автоматизировать процесс «вычленения» этого «добра от Fabric» такой же ад. Вот эти «подсказки» с интеграцией и визарды мне напоминают «скрепыша» в 90-х годах MS Office — пользы ноль.

PS. Перечитал — как-то получается что я здесь выступаю хейтером Fabric. Но я, честно, не хотел этого, просто резануло глаз, что такой высокий балл в статье отдали именно Fabric — я не понимаю за что, стоимость интеграции у него гораздо выше.

Послушал минут 30, хех что тут сказать… Ах да, такое ощущение что Microsoft это фабрика всякого дерьма, которым оно заражает весь мир, а потом его (дерьмо) бросает и создает новое (аджаил блин), а куча обманутых пользователей потом по конфам Microsoft ходят и задаются вопросами по старому дерьму, а Microsoft уже(!) рассказывает про новое и ничего не слышала про старое.

Мы о разных вещах говорим, вы про типичный российский крысятник (до 100 человек), я же про либо региональный филиал крупной российской корпорации, либо про дочернюю компанию иностранной компании в РФ (авто/кондитерка/нефть). В типичном российском крысятнике делать нечего даже на этапе собеседования(но это я отвлекся), и я почему-то думаю, что «сергей» ну никак не мог решить со своей ипотекой, видя ставку крысятника, во главе крысятника естественно король крыс из «Щелкунчика».

Пусть эта фраза не вводит вас в заблуждение, в таких компаниях квартальная премия платится за выполнение ранее поставленного плана, а сводят они(по сути заинтересованные люди) баланс настолько красиво, что как правило, этот самый план всегда выходит выполнен (сводится в ноль, кому как привычнее слышать).
Эх, жаль, название конторы-то не сказали, а то по некоторым признакам там еще есть и производственные отделы, и даже конструкторский отдел ) Это ведь намного-намного увлекательнее могло быть начало, типа «в первый день сотворения Компании был поставлен турникет, и первые люди сразу начали ходить через него, а потом вырасли стены конструкторского отдела...»

Я считаю, что не было в тексте ни одного момента где бы Сергей получил бы повышение. И не важно, какие там технологии и не важно какие там будут условные «сергеи» с горящими глазами или нет, испорченные они или нет. Один результат — никаких повышений никаким сергеям в таких компаниях не видать. Какие P&L? О чем вы говорите, история ведь повторила итерацию зимой, а что у нас зимой? — Годовой отчет с закрытием финансового года.
Могу предположить что запарка с закрытием периода, со сведением несводимого и проводками у финансового отдела (бухгалтеров) была из-за того, что кто-то в компании мутит с товарными позициями по черному. И уверен что делается это группой лиц, и даже почему-то не буду удивлен, что вот эта вот дама, условная жанна с крамольной «задачей реального бизнеса», всего лишь ширма, за которой таится яма безисходности в которой тонет и засасывает. Что сергей хотел оптимизировать? Колян-то небось на этот момент уже был в курсе про мифические остатки на складе и левые проводки с логистикой или сетями?
Как мы знаем прописную истину, сотрудники уходят не из компании, сотрудники всегда уходят от других людей. Вот здесь кроется все самое-самое главное. От других людей уходят. Вот в этом направлении я бы и копал — начиная с завхоза, старшего менеджера логистики и «продажников». Скорее всего именно от этого списка убегали эти николаи и сергеи, а не от условных битриксов или «ужасного» кода.
Сергей мог бы получить повышение (стоп, а что такое повышение вот этого Сергея? На таких компаниях это всегда — слив условной Жанны.) если бы он тихо начал бы исследовать предметно источники всей этот текучки, и главное(!), а это всегда ключ к повышению (тьфу) решению, выяснил причины по которым конкретные люди не увольняются. То вот тогда бы, можно было бы писать докладную записку на главного (только на самого главного, владельца бизнеса, а не кантри-менеджера который вполне может быть и в доле), где он бы во всех красках рассказал по каким реальным причинам дяди и тети сводят несводимый баланс и рисуют упомянутый выше P&L репорт. Вот тогда, бы история была бы намного интереснее.

Как показывает практика, книги, собственный опыт проведения собеседований, да и подтверждают давние дискуссии на различных технических площадках (за последние 15-20 лет) список вопросов почти один и тот же, а вот список «правильных» ответов на эти вопросы всегда меняется из года в год и от одной головы к другой.

1. Этот механизм бана широко используем и широко известен, по крайней мере, для пользователей reddit.com. 2. Ошибок у данного механизма быть не может, он давно оттестирован и эффективно борется со спамерами. 3. Количество «статей» написаных на разных ресурсах после факта понимания что механизм a)широко исзвестен и б)широко применяем говорит лишь о том, что робот reddit все же не ошибся с баном. Теперь по существу, по роду занятий нахожусь в штук десяти разных геймдевовских комюнити различных направленности от тестирования игр до проектирования игровых интерфейсов, но блин приходит такой вот автор и фигачит во ВСЕХ бордах один и тот же текст. Прямо «центр американского английского» из 90-х!

Я руковожу небольшой коммерческой компанией из 10 человек(своей), первый проект наш был на мои личные сбережения (25К USD) прибыльность составила около 350%, я так же имею опыт руководителя (в иных компаниях) инженерных групп около 15 лет, и успешный опыт продаж на зарубежную аудиторию около 7 лет. По одному из моих вузовских специализаций — я финансовый аналитик, я прекрасно разбираюсь как в области так и в анализе.
В финансах говорят так «будущее достаточно легко проанализировать, гораздо сложнее проанализировать прошлое». Строятся модели, создаются сценарии, рассчитываются вероятности. Здесь вообще просто — работа идет только по цифрам. Мне например кажется, что вы неправильно анализируете прошлое, ибо выводы категоричные, они основаны на субъективных факторах. Вот любой пункт берем «Если компания не взлетает в течение 18 месяцев» — откуда эта цифра? Она вообще расчетная. То есть она может любой, зависит от проекта, области, страны, и тд и тп. Или «Важно фокусироваться не на приоритизации существующих задач» — а с другой стороны что может быть важнее плана? «Нельзя поднимать мало денег» — нельзя терять МНОГО денег.

Алексей, простите но не верю я в ваш «типичный рабочий месяц» по 9h, вы в таком темпе через три недели ласты «склеите». Дело в том что, есть некая норма выработки инженера, либо людей условно к ним причесляемых, он эту выработку делает точно за 5 часов, этих людей нельзя выжать чтоб они работали больше этих условных 5 часов, к сожалению этому сопротивляется мозг, люди которые делают то же, но за короче время — являются более опытными или более умными коллегами, обычно занимают выше должности ( условно должности ведущих инженеров и выше) а те кто работают за 5 и выше часов — это те кто не доросли до инженеров.
Стоит заметить, что здесь есть ряд очень важных допущений, например, во время релизов или стрессовых ситуаций инженеры могут работать больше, но это лишь потому что их мозг мобилизируется на время, он «берет в кредит» в коротком плече но не больше плеча в 2-3 недели, после — кредит придется возвращать.
Жаль что вы так глупо просадили деньги инвестора, те товарищи которые начинают стартапы «за свои» обычно сразу начинают со свот анализа и аналитики будущих продаж. ЧТоб не было как у вас

Речь идет не о дюймах и разрешении экрана (кстати для плюсовых моделей iPhone их аж три и игроделы это знают — a) режим обратной совместимости с iPhone 4 доступен только на старом iOS c старым xCode и на маркете их почти нет, б) режим совместимости с большинством не Plus-устройствами таких игр 80%, в)режим совместимости с Plus — таких игр где-то 20% на рынке — их отличает повышенная четкость в глифах использованных шрифтов). Речь идет о технологическом решении — будут ли «черные уши» в OpenGL или будет слепая зона — и все, меня как профессионала именно это интересует. И к сожалению на сегодня это для меня не ясно, возможно информация появится в ближайшее время.

И как под iPhone X игры писать? Круглые края предполагают либо слепую зону (геморрой для разработчика) либо пассивные уши (убожество) либо активные уши — с интерфейсом Touch Bar (меньший геморрой для разработчика, но все равно прийдется делать дополнительный перезапуск на AppStore).
Короче все три решения — разные по степенью геморроя и убожества