Ainur Shakirov

var array = [2, 5, 7, 12, 25, 36, 9, 222, 55, 34, 73, 29];
var i = array.indexOf(25);
if(i != -1) {
	array.splice(i, 1);
}

>> [ 2, 5, 7, 12, 36, 9, 222, 55, 34, 73, 29]

CSS нельзя изолировать, по этому лучшее решение - namespace. Это добавит уникальности стилям и не придется писать не нужный important везде.

.my_moudule_namespace--class_name {
    ...
}

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

Я пользовался vmware converter для таких целей.
В итоге получается виртуальная машина - полная копия сервера с центосом.
Которую потом можно запустить хоть дома на домашнем компьютере.

Если вы задаетесь такими вопросами, значит у вас уже есть потенциал.

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

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

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

Скопировал дизайн по заказу Upwork, когда придет ОМОН?

Вам, точно ничего.
Теоретически на вашего заказчика могут подать в суд, но это опять же будут его проблемы, а не ваши.
И то маловероятно.

Минус в карму.

Gradle — система автоматической сборки, построенная на принципах Apache Ant и Apache Maven, но предоставляющая DSL на языке Groovy вместо традиционной XML-образной формы представления конфигурации проекта.

когда у вас в проекте под 20 зависимостей тогда поймете зачем gradle ))
поставьте AndroidStudio - бегает быстрее, подобных проблем не замечал и сама на базе idea, тоетсь привычные плюшки там есть

Я бы предложил вам следующий вариант - изучить в порядке популярности наиболее часто используемые элементы интерфейса. Например, ListView, GridView, RecyclerView, SwipeView/ViewPager, Fragment Manager и т.д. Это базовые элементы и вы можете увидеть их почти в каждом современном приложении типа Viber, TuneIn и т.д. Туториалы вы можете загуглить по каждому отдельному пункту.
А когда захочется сделать что-нибудь оригинальное и выходящее за рамки базового функционала Андроид, то обратите внимание на эту коллекцию https://github.com/wasabeef/awesome-android-ui
Удачи!
Туториал по ListView
Туториал по GridView
Туториал по RecyclerView
Туториал по SwipeView
Туториал по Fragments

Подходят. При изучении чего-то из программирования, делай упор на язык/платформу/SDK/whatever, а не на IDE. IDE приходят и уходят, а всё остальное - остаётся.

php.net/manual/ru/function.array-multisort.php
там есть пример

Адаптировать или нет - зависит от проекта и, к сожалению, желания и бюджета заказчика. Не адаптивные проекты встречаются все реже, но и в них используем как минимум модульную сетку.
Количество контрольных точек, в которых перестраивается макет, и их значения зависят от дизайна, также бывают дополнительные медиа-запросы для элементов, которые на какой-то ширине/высоте начинают плохо выглядеть.
Основной принцип - конкретный дизайн должен хорошо выглядеть всегда, без привязки к размерам конкретного устройства (но дизайнеры все равно рисуют 320, 768 и "большой" - какой? по настроению дизайнера), все, что не нарисовано, додумывает верстальщик на ходу.
Элементы форм, анимацию, кнопки, ссылки - все, с чем взаимодействует пользователь, также делим по принципу тач/не тач.

codepen.io/anon/pen/adYQZB

Мне, как разработчику, удобно, если дизайнер знает технические особенности отдельных элементов. К примеру, расположить иконку для кнопки размером 20х20 пикселей на прозрачном холсте 40х40 пикселей, чтобы мне после вставки маленькой картинки в кнопку не приходилось расширять активную область вручную. Неплохо еще, если дизайнер представляет примерно как работает autolayout. Еще как iOS разработчик каждый раз хочу убить дизайнера, рисующего такие границы, которые дробно масштабируются на Retina дисплеи.
А по поводу отдачи в готовый файл интерфейса - я думаю это лишнее. Во-первых, в файле интерфейса есть чисто программерские вещи: аутлеты, теги, runtime атрибуты. В условиях ускоренной разработки, когда дизайнер и девелопер какое-то время работают параллельно, придется свой файл интерфейса просто выкинуть и все настраивать заново. Во-вторых, на моей практике, часто применяется смешанный подход, когда часть элементов грузятся из интерфейснго файла, а часть - из кода.

P.S. Это конечно мои хотелки как девелопера, уверен что истина где-то посередине:)