Но до сих пор этот рынок не породил ни одной IT‑фирмы, которая разрабатывала бы собственные продукты и продавала их по всему миру.
Откройте prom.ua и промотайте до конца страницы. Фирм мало, но они есть.
Переливка (ETL) кликстрима из HDFS в вертикальную базу данных для последующего анализа.
SAP ABAP Developer
Конечно, это и для мальчика непросто. :)
Зафейспалмь себя сам. :)
Есть большая разница между обучением в наших университетах и известных заграничных (Стенфорд, Гарвард, MIT). В том числе и распологающая к развитию среда, о которой ты упомянул. И она очень важна.
У нас проблема в том, что программа не успевает адаптироваться под отрасль, преподаватели в большинстве своем некомпетентны (т. к. не являются практикующими разработчиками), а студенты — незаинтересованы (т. к. не знаю почему, но у нас 80% группы ушло в торговлю). Если удастся найти университет, где эти три проблемы отсутствуют — можно поздравлять с цветами. Если не удастся, см. мой первый комментарий.
Привет. Это абсолютно неважно. Только самообучение делает из студента специалиста.
О, дни Хабры на ДОУ? Там тоже любят высказывать экспертное мнение по поводу стоимости акций Фейсбука. :)
Очень интересная тема. 144 комментария. Спасибо.
Зато есть еще 16 часов в сутках, часть из которых можно потратить на горизонтальный рост самостоятельно. А еще можно сменить работу на такую, в которой есть возможность знакомиться с новым.
Аутсорсовая компания заказчика из-за этого не поменяет никогда. Поменять заказчика можно проще — перейти в другую компанию / на другой проект. :)
Насколько я Вас понял, проблема здесь стратегическая. Если заказчик не технический, то он не должен диктовать исполнителю, какие решения принимать. Как у Лебедева было:
Нормальная веб-студия.— Нет.
Решение, которое Вы описали, приемлемо в такой ситуации, но было бы лучше наладить связь с заказчиком и пояснить ему, что не делая рефакторинг, он теряет деньги. Согласен, не всегда получается. Всегда есть еще один, более радикальный вариант — поменять заказчика.
Пишете на Java?
Усложнять логику и писать абстракции нужно тогда, когда метод без этого превратиться в монстра. Если начать писать абстракции раньше — то вы превратите его в монстра помимо его воли. :)
Многие работают по Эджайлу используют Скрам, Джиру и кучу другого софта с красивыми графиками и диаграммами, но забывают простой закон — простое лучше сложного. Потому что понятнее, быстрее в разработке и содержит меньше багов.
Абстракцию нужно писать когда система усложняется. Кэшировать и масштабировать базу — когда увеличивается нагрузка. Раньше — не лучше, чем позже.
Аджайл дает возможность менеджеру прикинуть, на каком этапе будет проект к концу спринта, и высказать предположения заказчику. Если стартап не понаодалживаю денег у всех-кого-можно, то ему это не нужно. По-моему, стартап может взять из аджайла отдельные *принципы*, такие как «код важнее документации» или «люди важнее процессов». Многие другие инструменты можно смело игнорировать — они не нужны в небольшой команде с постоянно меняющимися требованиями.
Прежде всего, нужно понять, чем бы хотелось заниматься. Классическая модель приложения — это хранилище данных, уровень логики (движок, реализующий основную функциональность) и уровень представления (то, что видит пользователь). Соответственно, разработчики делятся на back-end и front-end. Первые отвечают за работу с хранилищем данных и бизнес-логику. Вторые — за пользовательские интерфейсы. Помимо этого, есть разделение по проектам — enterprise-системы, внедряющиеся на больших предприятиях, web-проекты (dou.ua), мобильные приложения (для IPhone/Android).
Не смотрите на уровень зарплат в разных областях, прежде всего думайте о том, чем бы хотелось заниматься. Не бойтесь ошибиться — все равно вы рано или поздно придете к правильному решению поменять сферу деятельности, если старая не будет вас устраивать.
Совет найти программиста, который стал бы наставником, поможет быстрее расставить приоритеты и понять, что нужно знать и уметь в первую очередь.
Игнорируйте местных троллей, пытающихся компенсировать свою неудовлетворенность насмешками. Думайте в первую очередь о том, что вы хотите сделать — понимание этого необходимо для того, чтобы начать искать ответы — у знакомых программистов, в статьях и книгах.