Только я бы сказал, что задача «затроена»: движок для выборки пользователей, поведенческая статистика (не анонимизированная), и инфраструктура рассылки. Первые две части для нас самые важные, а инфраструктура рассылки пока примитивная. Собственно об этом упоминается в статье, когда нам нужно будет рассылать различным типам получателей (другие мобильные платформы, смски и так далее), то эту часть вполне можно заменить облачным сервисом, эту часть особо развивать и не планируется.
А по вакансиям не скажешь! Работодатели люябт full stack разработчиков. Попробуйте посмотреть на ситуацию с точки зрения стартапера. Это что, для самого маленького проекта нужен бекнед, фронтенд, разрабы, спец по БД, спец по адроид, спец по айфон, спец по винфон?
Я так понимаю вы про разработку аппаратуры, так про нее речь не идет. Видите, вы же сами пишите, у вас выбор идет между 3 системами. В программировании ситуация другая, чего стоят только сайты вроде: todomvc.com/ Речь идет о десятках похожих эволюционирующих, появляющихся и исчезающих инструментов
Собственно об оценке и пристреливании речь. С одной стороны это не сложно, но эти проекты плодятся как кролики, поэтому вся проблема в огромном количестве этих новых технологий.
А попробуйте посмотреть на проблему с другого угла — с позиции техлида. Да, взятые в конкретно взятом проекте технологии освоить не сложно. Но вот вы начинаете новый проект, и вам нужно выбрать. Ну вот навскидку, я например хочу выбрать решение для cluster membership, и вот я вижу что популярными технологиями являются: zookeeper, etcd, consul, serf, doozer. И мое понимание принципов на которых построены эти системы никак не избавляет меня в потребности убить кучу времени на их изучение и сравнение.
Ну вот видите, вы не в теме :) NoSQL и SQL нельзя сравнивать напрямую — они для разного класса задач. И выбрасывать реляционки конечно не стоит, обычно в хайлоаде несколько разнотипных хранилищ используют.
Если эти пара компаний — это места где ты именно хочешь работать, то для тебя это таки субьективно «твои навыки никому не нужны», где «никому» — это круг интересных тебе компаний :) Конечно, у все свой уровень ожиданий, и для кого-то озвученные проблемы не существуют, тут вы конечно правы.
Заказчиков можно, я думаю, и с коболом найти :) Тут скорее важно в каком направлении идут прогрессивные компании. А они идут в облака, nosql, автоматизацию, виртуализацию и так далее.
Я отвечал на вот это «Нужно использовать то, что знаешь ты, а не распыляться.», и это как бы не подразумевает изучения пары-тройки, а подразумевает не изучение :) Извините, может у меня уже проф. деформация и я все понимаю все дословно.
Да, проблема действительно существует. Я последнее время ее стал отчетливо ощущать. Видимо нужно пересмотреть свои взгляды на использование времени: помимо работы и жизни у современного разработчика должен быть план по самообучению. В ИТ конечно всегда требовалось актуализировать свои навыки, но удавалось это как-то распихать по статьям работы и жизни. А современный образ программиста — это этакий вечный студент, совмещающий работу и учебу.
А потом через пару леть пойти искать новую работу и понять, что твои навыки никому не нужны. Лично я считаю, что нужно быть в курсе трендов, и постепенно, понемногу мигрировать на новые технологии. Вся проблема в расстановке приоритетов. Хвататься за все нельзя, не смотреть что происходит в мире — тоже нельзя.
Нет здесь лекарства. Будете использовать только знакомое, сейчас это прокатит, но через 5 лет ваше отставание от распространенных технологий будет катастрофичным.
Согласен, но я бы скорее обобщил до такого: оценка вообще является довольно сложной дисциплиной, для овладения которой нужна мотивация. Всякие методологии конечно помогают, так как они создают некоторый набор ограничений, от которых можно отталкиваться. Но проще ведь сидеть просто писать код, и доказывать всем (порой весьма успешно), что задачу невозможно оценить и так далее :)
Коренная проблема в оценке сроков в том, что это пытаются сделать как некое пассивное предсказание, а нужно занимать активную позицию. Для удачной оценки нужно а) Определить приемлимый способ решения задачи, и понять какой срок приемлимый с точки зрения бизнеса. Тут что-то вроде торга, типа я могу сделать A за X или B за Y. б) Нужно стараться успеть попасть в этот срок, на ходу расставляя приоритеты и корректируя план работ на ходу. Понятное дело, что с чем-то будут проблемы, но важно всегда понимать насколько проблемная часть важна с точки зрения бизнеса. Возня с низкоприоритетными задачами — главная причина срыва сроков.
Вы опять пытаетесь ввести публику в заблуждение :) Это были собеседования на позицию сениора. Кстати в одноклассниках, куда я ходил, есть только позиции сениоров. Что касается других компаний, то позиция определяется в первую очередь уровнем отвественности, которую может взять на себя человек
Starting a basic website in 2014:
1. Install Node
2. Install Bower
3. Pick CSS framework
4. Pick responsive approach
…
47. Write some HTML
Взято вот здесь: twitter.com/iamdevloper/status/517616294909464576
P.S. Сингулярность уже близко!