strobegen

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

PS.
3 месяца не срок если вы хотите сделать качественный сайт решающий ваши задачи.

Вопрос не совсем коректно составлен - в вашем случае речь не про дизайнера а про компанию в которой проектом занимаются так же проект-менеджер и отвественный сотрудник с вашей стороны, работа всех сторон сильно влияет на результат.

Перспективы конечно есть, но навярняка Go так и останется узкоспециализированным языком как есть сейчас, будет занимать небольшую нишу - думаю вашим целям он не отвечает. Я бы предложил вам изучить
связку Scala+Java. Java только с той стороны, что по ней всегда будет много предложений работы, а вот Scala как очень хороший язык который совмещает всебе много концепций из разных других языков и при этом очень практичен - уже сейчас очень много компаний переписывают свои проекты на него (по этому есть не мало предложений где требуется знание Java и инфраструктуры, чтобы переписывать это все на Scala).

Также скорее всего сильно перспективен Rust - по сути еще нет стабильного релиза а интерес к нему уже очень большой.

Нужны описания best practices.
Скала страдает тем, что она немного перегруженна фичами и с ходу не очень понятно, что важно знать а, что не очень - например если с равнить с Ocaml то изучать его гораздо проще, но там заметно сложнее развернуть окружение для старта.

Также есть проблема с тем, что много документации по инфраструктурно-важным проектам не успевает за и их развитием. Например решил посмотреть Play, начал изучать документацию и понял, что все библиотеки для работы с базами данных уже устарели их место занял Slick но информации как его правильно использовать в контексе Play почти не найти, а та, что есть в основном по уже почти устаревшей версии Slick.

Я бы предложил вам добавить в список для рассмотрения Ocaml или F# (по сути это почти один язык)
- оба этих языка похожи на Scala, тем, что совмещают FP и OOP да и в целом сильно похожи, есть даже вот такое сравнение вместе с haskell: Languages with Type Inference: OCaml, F#, Scala, H...
- оба в неплохо развиваются в последнее время.

Но в отличии от скалы эти языки намного более лаконичны и просты, а в отличии от хаскела там при необходимости можно применять привычные методы работы.

Про тягости выбора рекомендую почитать вот это:
Replacing Python: Candidates
Replacing Python: Second Round


Clojure, Common Lisp, Scheme - я бы предложил оставить на потом тк в них нет мощной системы типов, разве, что можно вскользь познакомится с общими принципами лиспов тк не мало статей где базовые принципы FP рассматриваются на примере scheme.
Если судить по irc каналам Clojure сейчас дико популярна, больше чем скала примерно на уровне Haskell.

тоже задавался этим вопросом - у них гдето на qt-project.org в faq написанно, что можно запаковать либы в банд и зашить в приложение, тогда это считается динамической линковкой, и рядом приписка, что якобы айпл может не за апрувить такое приложение

- т.е по идее запаблишить скорее всего можно, но ни кто не гарантирует, что айпл будет пропускать ваши приложения

git это само собой (bitbucket тут самое очевидное решение), а еще есть osx server (щас они его раздают бесплатно участникам ios dev программы) в котором есть родная тулза для continuous integration xcode проектов - соответсвенно если заведете dev сервер то можно будет настроить автоматический билд проекта из git репозитория

У меня было так, пообщался с несколькими кандидатами (заказ был по Unity3d) выбрал одного человека который казался очень адекватным (из тех что до меня были отобранны овнерами организации) - кандидат показывал примеры своего нормального кода, примеры довольно интересных проектов, говорил, что у него есть в команде дизайнер с которым он постоянно сотрудничает (тоже показывал его работы они были так себе но под задачу этих скиллов было достаточно) - вобщем договорились о первом тестовом такске с предоплатой 100$ (по сути это было тестовое для дальнейшего долгосрочного сотрудничества над большим по часовым проектом), задача была разжована максимально, никакого творчества не подразумевала. После старта и получения предоплаты он пропадал и на все сообщения кормил разные байки, вообщем гдето через недели 2 после предполагаемого завершения таска он пропал окончательно так ничего и не показав - но через год он написал поздравление с днем рождения :)

Думаю, что этот случай не правило, но нужно понимать, что у них несколько другие представления об ответсвенности, сроках, и исправлении своих ошибок.

есть еще один вариант взять в аренду mac-server и билдить там (но стоит дорого и на устройстве не получится отлаживать да и чтобы просто приложение заинсталить придется проделывать кучу не нужных шагов).

А если говорит про удобство разработки то в порядке предпочтительности:
1). Если есть деньги на мак (хотябы б.у. macmini) лучше купить его (думаю при желании можно баксов в 500-600 уложится).
2) Хакинтош - довольно геморно установить и заставить работать, но когда заработает особой разницы с настоящим маком не будет (но как минимум раз в год будет ждать очень неприятная процедура апгрейда ОС до новой версии (с возможной потерей данных и кучи настроенного софта))
3) Виртуалка - в принципе для многих применений вполне достаточно - особенно по началу, если будете осваивать нативные средства разработки.

Единственное SDK которое собирает приложение без наличия доступа к маку хотябы в качестве билд-сервера (например такое есть в Xamarian) с которым я сталкивался это MarmaladeSDK, но даже там в стор вы приложение без мака не отправите. В MarmaladeSDK собирается ARM бинарних который подписывается айпловским сертификатом, но с ним тоже куча проблем - в частности просто так на устройстве не поотлаживаешь, нужно работать с VM а она не редко можеть пускать то, что на реальном устройстве будет падать ну и сам Marmalade стоит денег, причем только в виде подписки, да и сам SDK больше подходит большим компаниям которые готовы покупать поддержку и самостоятельно портировать необходимые библиотеки на него.

Обращать внимание нужно всего на две вещи - делает ли человек работу и его коммуникация. В плане поиска единственное, что можно посоветовать это развивать свои навыки коммуникации - популярные методы вроде проверки наличия X работ в портфолио, по факту ничего не дают (даже вероятно отсеят много хороших людей). Также надо четко разделять понятия фрилансера и удаленного работника.

13" Retina — плох мелким диском и невозможностью апгрейда памяти — вам скорее всего рано или поздно
понадобится работать на 2х ОС, соответсвенно 128 гиг для этого маловато ну и 8 гиг оперативы не так уж много (у меня не редко бывает занято 10-15 гиг во время работы). Соответсвенно возможно будет лучше взять обычный Pro 13, примерно за $100, поставить 16 гиг оперативы, заменить диск на SSD (примерно $200-$400 взависимости сколько нужно 256, 512) (родной hdd можно поставить вместо сдрома, нужно лиш купить hdd cady, а сам сидюк юзать по необходимости через usb переходник). А что касается ипада то думаю нет его смысла вам брать, покрайнемере сразу — тестировать сайты можно в iphone/ipad simulator который ставится вместе с xcode (там есть разрешения всех ios девайсов).

как известно почти у всех произодителей камней, софт за редким исключением заточен под винду, во многих случаях конечно можно помучится и настроить под мак — но рациональнее поставить на мак vmware или parrallels и завести там виртуалку с виндой либо прямо раздел с буткампом туда засунуть — и просто возится со всей электроникой из этой виртуалки, производительности сейчас вполне хватает чтобы даже не замечать, что у вас круглосуточно в фоне запущенна VM, работает все достаточно шустро + там довольно удобная интеграция по доступу к файловой системе мака — т.е это спасает от малополезной траты времени.

www.guru.com — там нету как на odesk ориентированости именно на работу по часам, но с клиентами об этом вполне можно договорится (причем некоторые при обсуждении проекта говорят желаемую ставку в час), у них там перед каждым проектом составляется договор в котомром можно договоренности по часам закрепить.

у меня еще ctrl+option(Alt)+S работет, но к сожалению не помню уже — так сразу было или, я что-то настраивал для этого