• Что значит, когда в вакансиях пишут "Опыт с одним из фреймворков: Symfony, Laravel, Yii"?

    opium
    @opium
    Просто люблю качественно работать
    Это значит если вы осилили один то достаточно легко сможете писать на другом
    Ответ написан
    Комментировать
  • Стоит ли идти учиться в ВУЗ будущему программисту?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Будущему программисту нужно научиться пользоваться поиском. Без умения самостоятельно искать и анализировать информация, карьеры в этой области не сделать.
    Ответ написан
    Комментировать
  • Почему PHP теряет популярность?

    AleksandrB
    @AleksandrB
    Совсем недавно вывел "Hello world"
    PHP не мода, php - классика, а классика никогда не умирает. Если умрет php, то умрут все остальные языки backend разработки потому что появится что-то такое, что сможет в разы превзойти пхп в простоте, скорости и удобстве, на данный момент что джава, что питон, что руби +- одинаковые, каждый подходит для своих целей. Тот же питон выбирают из-за простоты интеграции нейронных сетей, но если говорить не о узких, а о главных параметрах (функционал, скорость и тд) все популярные бэк языки более или менее одинаковые смотрите те же сухие графики.
    А о уменьшении вакансий - глупость несусветная. трын тут приведена статистика за 2018 год и обоих графиках по вакансиям лидирует в сравнении с java/python PHP, при том на первых двух пишут как бэкэнд, так и миллион других штук. А на втором графике и вовсе пхп опережает js (единственный язык в самой популярной сфере разработки).

    А вот если речь идет о реально крупных компаниях (amazon, google...) там как раз предпочитают python из-за выше упомянутой простоты интеграции нейросетей, а java из-за стабильной поддержки сверх высоких нагрузок.

    Меньше слушайте диванных экспертов, пхп предрекают смерть с 00-х годов, что то он слишком долго дергается для мертвеца.
    Ответ написан
    1 комментарий
  • В каком стеке web технологий одновременно: высокий порог входа, высокие зарплаты и в целом не проблема найти удалёнку?

    Bandicoot
    @Bandicoot
    Вась-программист
    Backend-разработка.

    Порог входа - высокий, т.к. нужно много технических знаний, подкрепленных практикой.
    Зарплаты - в целом по рынку хорошие.
    Эти 2 фактора коррелируют между собой. Высокий порог входа как правило подразумевает высокую зарплату и наоборот.

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

    Обратный пример - работа дизайнером на удаленке/фрилансе. Очень многое зависит от заморочек в голове заказчика. Тут оттенок для него не тот, здесь шрифт другой нужен. Работа может приниматься очень долго, а кушать хочется сейчас.
    Ответ написан
    3 комментария
  • Как быть хорошим junior?

    saboteur_kiev
    @saboteur_kiev Куратор тега IT-образование
    software engineer
    1. Адекватность и самостоятельность.
    Детальнее: Умение понять суть задачи, чтобы выполнить ее. Самостоятельно решать проблемы - в это слово входит не только то, что возникла проблема - порешал. А умение решить проблемы, которые ты решить не можешь. То есть организовать решение проблемы. Заблочили аккаунт? Выяснить, вызвонить, попинать, чтобы разлочили побыстрее. Не знаешь как решить какую-то техническую проблему - достучаться до куратора. Не сидеть и ждать три дня, пока он вспомнит про твою проблему, а регулярно уточнять. Занят куратор - подойти к другому. Не успеваешь решить в срок - прийти к куратору заранее, а не за час до конца срока.
    В общем, чтобы за тобой не бегали.

    2. Умение ставить правильные вопросы.
    Сперва загуглить, потом задать вопрос для уточнения. В идеале ставить вопросы, на которые ответ будет "да" или "нет", но это я утрирую. Не бояться спрашивать вещи, которые совсем не понимаешь, но тут не нужно ожидать что все будут разжевывать - следует задать вопрос, чтобы понять куда копать. Иногда достаточно знать пару ключевых слов, по которым можно загуглить.

    3. Желание учиться.
    Не бояться изучить лишнее, потому что "мне же это не пригодится". Умение гуглить по ключевым словам. Не лениться изучать как что-то работает, чтобы понимать почему это происходит. Понимание принципов работы очень сильно увеличивает интуицию.
    Ответ написан
    1 комментарий
  • Какие выбрать платные курсы по изучению php?

    Для начала книги почитайте, основы поймете.
    Сложное тоже, но будут вопросы. Тогда Вам и нужны будут курсы, главным образом не для обучения, а для знакомств и общения с такими же как и Вы.
    Курсов полно в Интернете, для начало все изучайте самостоятельно, но записывайте вопросы.
    Когда прочитаете 3-4 книги и посмотрите 3-4 курса, только тогда будет минимальное представление, что Вам нужно. Тогда и идите на курсы.
    Если по ходу самостоятельного обучения не возникнет вопросов, берите задания на фриланс биржах по минимальной ставке, будет задание - вопросы точно появятся. Тогда идете на курсы.
    Ответ написан
    Комментировать
  • Какие темы изучить для прохождения отбора на Python?

    irestone
    @irestone
    Junior Web Developer
    Во-первых: "На все это у меня есть пару недель.(Поверьте я псих, и не такое могу)" - нет, не можешь. За пару недель можно изучить некоторые технологии, но научиться правильно думать нельзя.
    Во-вторых: "На Видеокурсы времени нет! Нужна текстовая информация!" - видео усваивается лучше. Но, в целом, нужно комбинировать все возможные ресурсы.
    В-третьих: "JavaScript (НЕНАВИЖУ)" - нет смысла ненавидеть молоток. Это очень наивная позиция. Выбери задачу и используй то, что нужно.
    В-четвертых: Объем математики определяется целью: занимаешься машинным обучением, искусственным интеллектом и прочим дата сайенс или пишешь физический движок, например, - понадобится серьезная математика. В остальных случая хватит школьного курса, и то средней школы.

    Непосредственно подготовка:
    Cracking the Coding Interview
    Elements of Programming Interviews in Python
    Из этих книг тебе станет ясно, что нужно знать, чтобы пройти собеседование на работу.

    Тренируй problem solving скилл на специальных сервисах. Популярные: https://leetcode.com, https://www.hackerrank.com, https://practice.geeksforgeeks.org
    Нужно не просто решать задачи, а учиться это делать правильно, походу изучая алгоритмы, структуры данных и анализ сложности. Грокаем алгоритмы - хороший выбор. Будет отлично, если найдешь друга, с которым можно будет тренировать witeboard'ы, когда один берет на себя роль интервьюера и задает другому задачу. Это важно. Так вы сможете разобраться, где и почему вы застреваете и научитесь правильно выстраивать мыслительный процесс при решении задач. По большому счету, это твой основной навык как программиста, именно его и будут проверять в первую очередь при собеседовании на работу. По крайней мере, должны. Если спрашивают только конкретные технологии, то тебе стоит задуматься, стоит ли у них работать. (Подсказка: нет)

    Изучай ООП и Паттерны проектирования.
    Все доступно и с примерами.
    Видео по одной популярной книге, которую тоже можешь начать читать.

    Изучай инструменты (языки, фреймворки и пр) под конкретную сферу. Не надо изучать все подряд, учи то, что нужно для того, чем ты хочешь заниматься, конкретный стек технологий. Помни про принцип Парето.
    Например, вот хорошие ресурсы по питону:
    https://www.amazon.com/dp/1593279280/
    https://www.amazon.com/dp/1593275994/
    https://www.youtube.com/watch?v=8DvywoWv6fI

    Наконец, ты должен понимать, что нетехнические, т.н. софт-скиллы не менее (а в случае с джуном часто более) важны. Я не зря предлагал ресурсы на английском - этот язык разработчику знать важнее, чем любой язык программирования. Не знаешь, с чего начать? Посмотри "Полиглот. Выучим английский за 16 часов!", начни пользоваться https://lingualeo.com (там есть и тренировки и курсы)

    Окружи себя инфосферой: ютуб, твиттер, телеграм и пр.
    Мне, например, нравятся эти ребята:
    https://www.youtube.com/channel/UCVbz7l0COUdLupcY4...
    https://www.youtube.com/user/HexletUniversity
    https://www.youtube.com/channel/UC4xKdmAXFh4ACyhpi...
    Они помогут тебе начать думать в правильном направлении.

    Удачи!
    Ответ написан
    3 комментария
  • Попросили проверить код, на что смотреть нужно?

    apavlyut
    @apavlyut
    www.pavlyut.ru
    Все комментаторы совершили одни и те же ошибки управления потому что, при всем уважении, скорее всего за эти ошибки (в стратегировании) они не платят из своего кармана.

    На пальцах отвечаю на ваш вопрос:

    1) По структуре - при проверки качества кода / решения / задачи / продукта / настройки сервера и так далее нужно проходить по списку (чеклист) критериев контроля качества - обычно они выглядят как списки определенных параметров которые может замерить третье лицо или сама система - формат проверяемого параметра прямо вот соответсвует / не соответсвует. На сколько процентов пройден чеклист - на столько процентов результат "качественный"
    2) Почему ребята ошиблись - потому что стали приводить конкретные списки. Дело в том что у каждого проекта / сиутации / команды / набора компетенций - свои наборы таких чеклистов на разные ситуации. В больших командах сущесвтует основной чеклист который регламентирует CodeReview - и за него отвечает как правило тим лид - он его обновляет, развивает, обосновывает внесенные правила и следит за тем чтобы ПЕРЕД началом разработки все разработчики были ЗАРАНЕЕ ОЗНАКОМЛЕНЫ с этим порятком проверки качества, а все потому что:
    3) Количество стайлгайдов и критериев в приципе существует огромное количество - и то как каждому в одной части света / компании удобно делать одно дело - не регламентирует ни разу что именно так же другому человеку в другой ситуации применять эти правила к своему контексту. В виде открытых стайлгайдов они существуют для накопления практик и навыков в первую очередь для их же развития (процесс формулировки наводит порядок в голове) а также дают возможность "на них конкретно" нанизать точечные ответы огромного сообщества людей, и получить те самые разные взгляды на ситуации, и по возможности опять же привести к общему знаменателю. Но это все мелочи жизни, а в вашем случае вы совершите серьезную ошибку если прямо сейчас возьметесь (примите на себя ответственность) проверять чужой код на предмет оценки, потому что:
    4) Вас явно используют как внешнего эксперта на которого можно сослаться, от которого можно получить якобы аргументацию для давления на свою позицию при решении какой-то возникшей ситуации во взаимоотношениях клиент-разработчик на проекте куда вас приглашают за экспертизой.
    Если вы, не предупредив, о том что "качество кода" начинается с декларации этого качества (в случае если речь идет о проверке этого внутреннего качества в рамках сотрудничества, а не самих задач которые поставлены перед создаваемой системой - фичесов) - любая ваша оценка будет недостоверна контексту ее применения (вы напишете про строки или еще что-то - а у человека будут либо взыскивать деньги / либо недоплатят за работу / или инкапсулируют в договоренности пост фактум за те же деньги работу над соотвествием определенным стилям - это все работа которая должна быть оплачена). Поэтому вот вам вилка ваших дейсвтий:

    1) Если у вас просто просят менторства молодые коллеги - дайте им ссылку на гугл и ключевое словосочетание php style guide github
    2) Если вас спрашивают (либо вы сами являетесь таким заказчиком который ищет за что зацепиться в коде чтобы продавить свою позицию) - нет критериев качества кода ДО начала работ подписанных на бумаге / пересланных по почте - никакие критерии не могут быть применены к текущим отношениям - только к следующей итерации за следующие деньги.
    3) Если вы все же разработчик и вас попросили оценить код - донесите данную ситуацию до стадии корректного закрытия текущего этапа работ - но дальше предложите уже введение стайл гайда если оно того требует. Я полагаю что на самом деле нет. Дав сейчас ответ на вопрос в виде оценки качества кода вы сделаете только одно - абсолюно необоснованно дадите агрумент в явно перекошенном споре, и просто возьмете на себя еще один мешок кармогрязи которую будуете еще сколько-то положенного времени отрабатывать.

    Подумайте хорошо на эту тему - придется выбрать свою сторону.
    Ответ написан
    Комментировать
  • Попросили проверить код, на что смотреть нужно?

    edli007
    @edli007
    full stack, team lead
    Основное:
    1. Наличие критических ошибок и устаревших функций.
    2. Использование паттернов, элегантность решений.
    3. Читабельность кода, наличие коментариев, наличие доков.
    4. Соблюдение парадигм и соглашений ( например, нарушение MVC).

    Второстепенно\непринцыпиально:
    1. Быстродействие кода (за исключением хайлоад)
    2. Потребление памяти (за исключением бигдаты)
    3. Эфективность SQL запросов (за исключением совсем уж несуразных)
    4. Избегание в данных момент неважных, но потенциально узких мест (например замедление работы файловой системы при большом количестве картинок в папке аплоада)
    5. Новизна примененых технологий.
    6. Оправданое\Неоправднанное\Избыточное Велосипедирование.

    Мб еще вспомню.
    Ответ написан
    4 комментария
  • Попросили проверить код, на что смотреть нужно?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Смотря зачем)). Я когда делаю Code Review критерии следующие:

    * Безопасность:
    - Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
    - Никаких trigger_error, только исключения.
    - Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
    - Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
    - За eval как правило шлю на **й.
    - @ допускается только в безвыходных ситуациях, например проверка json_last_error.
    - Перед работой с БД - обязательная проверка данных.
    - Никаких == и !=. Со swtich - единственное исключение, по ситуации.
    - Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
    - Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
    - Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
    - Конкатенации в sql - только в безвыходных ситуациях.
    - Параметры в sql - ТОЛЬКО через плейсхолдеры.
    - Никаких глобальных переменных.
    - Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
    - Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

    * Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
    - В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
    - Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

    * Организация кода:
    - Никаких глобальных функций.
    - Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

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

    * Принципы MVC:
    - Никаких обработок пользовательского ввода в моделях, от слова совсем.
    - Никаких ***ть запросов в БД из шаблонов.
    - Никаких верстки/js/css/sql-ин в контроллерах.
    - В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
    - В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

    * Принципы SOLD:
    - Никаких божественных объектов умеющих во все.
    - Если метод для внутреннего пользования - private, никаких public.
    - Статические методы разрешаются только в случае безвыходности.

    * Принцип DRY разрешено нарушать в случаях:
    - Явного разделения обязанностей
    - В тестах (каждый тест должен быть независимым, на сколько это возможно)

    * Работа с БД:
    - Запрос в цикле должен быть РЕАЛЬНО обоснован.
    - За ORDER BY RAND() - шлю на***й.
    - Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
    - Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
    - SELECT * - запрещен.
    - Денормализация БД должна быть обоснована.
    - MyISAM не используется (так уж)) )
    - Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
    - БД не должна содержать бизнес логики, только данные в целостном виде.
    - Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

    * О людях:
    - "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
    - "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
    - "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
    - "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
    - "У меня все работает!" - рад за тебя, а как на счет продакшна?
    - "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

    * Всякое:
    ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
    То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

    UPD

    Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions
    Ответ написан
    56 комментариев
  • Программное решение для упорядочивания жизни?

    MrFrizzy
    @MrFrizzy
    список ссылок по похожим теме медиатеки\менеджера информации из моего загашника, может что приглянется)
    смесь опен сорса и проприетарщины
    где стоят плюсики - проект как минимум не вызвал отторжения при первом взгляде

    статьи по теме
    https://github.com/Kickball/awesome-selfhosted
    https://lifehacker.ru/2017/09/07/emusic/
    https://lifehacker.ru/2017/01/25/everlast-notebook/
    https://lifehacker.ru/2016/08/18/younity/
    https://lifehacker.ru/2015/05/22/rrrepo/
    https://www.one-tab.com/ +
    https://lifehacker.ru/chrome-tab-managers/
    https://lifehacker.ru/dropbox-new-app/ комбайн файлов, офиса, чата и задач
    https://devpew.com/knowledgebase/
    Программное решение для упорядочивания жизни?
    Есть ли todo менеджер с канбан досками и списками задач?
    https://zapier.com/blog/best-todo-list-apps/
    https://lifehacker.ru/servisy-dlya-produktivnosti/
    https://lifehacker.ru/luchshie-zametochniki/
    https://lifehacker.ru/notion-kollekciya-shablonov/
    https://opensource.com/alternatives/trello
    https://hackernoon.com/building-a-open-source-pers...

    # task managers
    https://lifehacker.ru/2016/06/14/hero-panel/ +
    https://lifehacker.ru/2017/01/30/mindful/ +
    https://sunsama.com/ +
    https://chrome.google.com/webstore/detail/jibjpmgd... +
    https://basecamp.com/features +
    https://www.gettoby.com/product +
    https://www.wunderlist.com/ru/ +
    https://kraevoy.com/category/planner/mylifeorganized +
    https://wekan.github.io/ +
    https://taiga.io/ +
    https://taskboard.matthewross.me/
    https://github.com/foradian/fluxday
    https://github.com/RestyaPlatform/board +
    https://kanboard.org/
    https://taskwarrior.org/ +
    https://getsoloapp.com/ +
    https://github.com/bram85/topydo +
    todotxt.org
    https://ultralist.io/ +

    # notes managers
    www.giuspen.com/cherrytree
    https://github.com/FourthByteLabs/giganotes-desktop
    https://github.com/dvorka/mindforger +
    https://simplenote.com/
    https://www.qownnotes.org/ +
    https://fromscratch.rocks/
    https://laverna.cc/
    https://boostnote.io/ +
    https://evernote.com/intl/ru/ +
    https://products.office.com/onenote +
    https://joplinapp.org/ +
    https://agenda.com/ +
    https://ru.wikipedia.org/wiki/TiddlyWiki +
    https://www.bookstackapp.com/ +
    https://github.com/cheat/cheat
    https://github.com/gleitz/howdoi
    https://asciidoctor.org/
    https://github.com/claudioc/jingo
    https://zim-wiki.org/
    wikidpad.sourceforge.net

    # bookmarks organizers
    https://bookmarkos.com/pricing +
    https://raindrop.io/ +

    # rrs & media readers
    https://feedly.com/i/welcome
    https://freadm.com/start/

    # file organizers
    https://www.tagspaces.org/ +

    # password managers
    https://www.keepassx.org/ +
    https://www.passwordstore.org/ +

    # platforms
    https://sandstorm.io/ +
    https://github.com/getgrav/grav +
    https://www.notion.so/ +
    https://perkeep.org/doc/compare
    https://makagiga.sourceforge.io/
    Ответ написан
    1 комментарий
  • Как правильно составить план самообучения?

    @php65535
    Для начала определись, чего хочешь на самом деле. Если твердо уверен в желании связать всю оставшуюся жизнь с программированием, советую пока сконцентрироваться на теории. Самостоятельно углубляйся в темы, которые дают в ВУЗе, подбирай дополнительную литературу. В качестве ориентира можешь взять программу одного из ведущих американских университетов, в интернете есть множество вариантов со ссылками на все необходимые материалы (пример). Всем этим стоит заниматься именно сейчас, потому что потом может банально не хватить времени и мотивации.

    Если же пока хочется просто заработать денег, стоит уделить больше внимания прикладным знаниям и практике с прицелом на то, чтобы как можно скорее устроиться на работу. Для начала следует определиться с нишей. Она должна соответствовать как минимум двум критериям:
    • Достаточная широта. Чем больше в нише компаний, тем статистически больше твои шансы найти работу.
    • Минимальное время, за которое можно получить навыки, необходимые для работы в нише. От начала обучения до трудоустройства тебя должно отделять 12-18 месяцев. Чем быстрее сможешь устроиться на работу и начать зарабатывать, тем лучше. Это даст хороший толчок как мотивации, там и твоему профессиональному росту.


    Я знаю только 2 ниши, удовлетворяющие этим критериям (заметь, это не значит, что других нет):
    • Мобильная разработка (Android, iOS).
    • Веб (фронтенд или бекенд). Ты правильно подметил, что в вебе большая конкуренция. Но конкурируют между собой в основном низкоквалифицированные работники. Минимально адекватных людей с базовыми знаниями отрывают с руками. Если потратишь год-полтора на правильное самообразование, то без проблем сможешь получить свои $1.5-2k (в Москве/на удаленке) на старте.


    Мобильную разработку и веб совершенно точно можно освоить за полтора года, если голова соображает хоть сколько-то. Подтверждений тому множество, есть они и на Тостере (пример).

    При выборе направления игнорируй безосновательные мнения задротов с их "настоящий мужик программист должен" и "X - плохо, пнятненько?". Все эти выпады - просто сезонное обострение синдрома вахтера.

    Когда определился с нишей, выбирай самый популярный в этой нише язык. Критерий популярности - количество вакансий на этом языке. Для разработки под Android это будут Java и Kotlin, для iOS - Objective C и Swift, для веб бекенда - PHP, для веб фронтенда - JS и TypeScript. Как уже писали, первый язык программирования - не приговор. Если ты хорошо освоишь хотя бы один, то сможешь без проблем перейти на другой (в той же парадигме) за 3-6 месяцев.

    Один из вариантов плана обучения такой:
    1. Заходишь на свой любимый сайт с вакансиями
    2. Ищешь 10 вакансий "middle %language% developer" (именно middle, это важно)
    3. Выписываешь все, что встречается хотя бы в 8 из 10 вакансий
    4. Гуглишь одну из тем по запросу "%topic% interview questions". Отмечаешь вопросы, на которые не знаешь ответа. Поначалу многое будет непонятно - это нормально, по мере изучения картина станет ясней.
    5. Гуглишь тему по запросу "%topic% introduction"
    6. Если попадаются книги, берешь первую попавшуюся и читаешь. Если книг нет, читаешь первые 5 статей. Как-то особенно заморачиваться с выбором книг на данном этапе вряд ли стоит: вводная литература вся примерно одинакова, и у тебя еще нет нужных знаний, чтобы отделить зерна от плевел. Если очень хочется, можешь попросить рекомендации на форумах/в чатах, где сидят программисты, работающие в выбранной тобой нише.
    7. Возвращаешься к пункту 4. Если еще остались какие-то непонятные вопросы, гуглишь их индивидуально.
    8. Повторяешь пункты 4-7 для каждой темы


    Если изучаешь какой-то практический навык (например, работу с системой контроля версий или язык программирования), обязательно подкрепляй теорию решением небольших, но реальных задач. Один из хороших вариантов - сделать какой-то свой проект и экспериментировать на нем. Если совсем нет идей для проектов, можно выбрать что-то из https://eax.me/programming-language-learning/ .

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

    Контролировать прогресс в теоретических вопросах самостоятельно трудно, желательно иметь внешнюю обратную связь. Один из вариантов ее получения - собеседования. Если на следующем собеседовании смог ответить на вопросы, на которых завалился на предыдущем, значит, прогресс есть)

    Практические задачи и проекты можно разбивать на небольшие завершенные шаги. Например, если делаешь мобильное приложение, которое выводит погоду в выбранном пользователем городе. Можно выделить следующие подзадачи:
    1. Создать проект в IDE
    2. Добавить главный экран
    3. Добавить на главный экран контрол выбора города
    4. ...

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

    Как только сможешь без подглядывания в Гугл отвечать на 80% вопросов с собеседований по всем темам своего направления, можешь начинать рассылать свое резюме. Лучше устроиться на работу как можно быстрее, но ни в коем случае не "за бесплатно". В компаниях, где платят мало, как правило, плохая инженерная культура, и никакого полезного опыта там все равно не получишь, а только потеряешь время.
    Ответ написан
    Комментировать
  • Какому языку, в какой среде начинать учить ребенка программированию 10 лет?

    10 лет это 3 класс

    Отстаньте лучше от ребёнка. Ему всего лишь 10 лет - какое программирование? Пусть он сначала насладится детством. А уже после - сам начнёт ковыряться в том, что ему понравится
    Ответ написан
    8 комментариев
  • Как работать с выгоранием?

    pospelov
    @pospelov
    Руководитель веб-студии
    Не работать в выходные и вечерами.
    Не работать в компании, где не комфортно работать.
    Не работать в режиме аврала больше 20% всего времени.
    Отдыхать раз в пол года.
    Развивать навыки хотя бы 5 часов в неделю. Что бы увеличивать скилы, либо личное КПД.
    ВАЖНО - приберитесь в задачах. Должен быть один единый центр, задачник. Трелло, Тудуист, бумажки, не важно.

    Если к вам всегда может подойти 5 человек, дернуть вас, и переформулировать задачу, отвлечь, поменять приоритеты, то вы всегда будете в стрессе и с выгоранием.
    Ответ написан
    2 комментария
  • Наиболее частые/популярные/типичные вопросы для обучения/интервью?

    sergey-gornostaev
    @sergey-gornostaev Куратор тега Python
    Седой и строгий
    Везде по-разному. Единственная закономерность, которую я смог заметить - у хороших компаний собеседования похожи на интервью или дружескую беседу. А если собеседование похоже на экзамен или допрос с пристрастием, то даже пройдя его, рад потом не будешь.
    Ответ написан
    3 комментария
  • Реально в 36-40 лет стать тестировщиком или программистом если есть свободное время?

    @kttotto
    пофиг на чем писать
    Реально. Таких примеров полно. Но все зависит от Ваших способностей. Сумеете год за три съесть инфы и отточить ее руками, т.е. по 15-16 часов в день отдавать новому профилю? Если да, то дальше для работодателя будет важно только Ваше умение писать код как минимум, должно быть портфолио Ваших работ, законченных и еще лучше опубликованных.
    Ответ написан
    Комментировать
  • Какова суть фреймворков и библиотек?

    Stalker_RED
    @Stalker_RED
    Библиотека это инструмент или набор каких-то инструментов.
    Бибилиотека для скачивания видео с ютуба
    Бибилиотека для кропа и ресайза картинок
    Бибилиотека для определения города по IP

    Фреймворк может использовать десятки или сотни разных библиотек. Это набор не только инструментов, но и готовых компонентов, и еще и рекомендация по их использованию.

    "набор для постройки скворечника"
    В комплекте молоток, гвозди, столярный клей, 20 деревянных досточек разных форм и расцветок и инструкция с тремая вариантами скворечника на выбор.

    Или вот два фреймворка:
    Ezva9I.pngzC6ZHT.png
    Можно ли их использовать вместе? (Конечно, никто не запрещает)
    Можно ли из этих деталей построить что-то совсем другое, не такое как в инструкции? (Конечно да)
    Можно ли с этими фреймворками использовать детали еще и из этого?
    lGjE1A.png
    (конечно можно, но придется что-то придумать для совместимости деталек. Быть может придется применить клей, изоленту, пластилин или жвачку. Или шуруповерт, или сварочный аппарат. Но ни в один комплект эти дополнительные инструменты не входят, как и скиллы к ним.)

    Можете посмотреть еще сюда, этот ответ частично покрывает ваш вопрос:
    Для чего нужны фреймворки, а-ля Laravel?
    Ответ написан
    Комментировать
  • Куда движется профессия системного администратора?

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

    IT Ops, на мой взгляд, поинтереснее (сам такой потому что), так как задачи разнообразнее. Но в DevOps, например, денег больше платят. Хотя в IT Ops сейчас тоже много из DevOps наприлетало -- Infrastructure as a Code, ansible/chef/puppet, хранение конфигов/плейбуков в VCS, вот это вот всё. И это действительно приводит к тому, что нужно меньше людей, чтобы управлять существенно бОльшими по размеру инфраструктурами. Но и квалификация этих людей тоже должна быть выше, и программерский бэкграунд какой-то тоже нужен. Потому что даже в IT Ops очень много автоматизации, которую нужно писать руками на Shell, Powershell, Python, смотря где как принято.

    Отдельный денежный сегмент -- это DBA. Oracle, PostgreSQL, MariaDB -- прокачанных DBA мало, и стоят они дорого. С другой стороны, рынок, где требуются DBA -- довольно узок. И чтобы не было проблем с поиском работы -- квалификация должна быть высокой.

    Есть ещё NetOps, т. е. сетевые инженеры. Но там сейчас грустно -- несмотря на то, что для работ в операторских сетях, например, нужна нефиговая такая квалификация и знание особенностей кучи вендорского железа (редко кто строит гомогенные в смысла вендора сетевого железа сети, в основном сборная солянка - -Cisco/Juniper/Mikrotik/Dlink/Huawei), но зарплаты там (по Москве) -- 90-100 тысяч. При этом практикуются ночные/выходные дежурства и всё такое. Можно найти прекрасные места, где сетевой инженер будет зарабатывать бОльшую сумму, но в целом -- как-то так.

    Если резюмировать -- в IT Ops ниже порог вхождения в целом. Т. е. можно найти работу, где не требуется серьёзная квалификация, но и денег будет соответственно.

    DevOps -- порог вхождения выше, т. к. DevOps подразумевает выполнение вполне конкретного набора задач, и для их выполнения уже вряд ли возьмут человека с улицы, надеясь, что он "по ходу разберётся" (а вот в IT Ops или даже NetOps в мелких и средних конторах ещё может прокатывать). Квалификация требуется выше, но и денег больше.

    DBA -- всё ещё сложнее, чем с DevOps. Рынок узкий, квалификация нужна высокая, но зарплаты тоже высоки, повыше DevOps, по моим наблюдениям.

    В чистый NetOps сейчас уходить... Ну такоэ... Есть крупные конторы, где этим можно нормально зарабатывать, но всё равно, квалификация требуется высокая, а денег относительно требуемого объёма знаний платят не так уж много. Вот IT Ops + NetOps -- это да, тут можно найти хорошую работу. Но для этого книжек придётся прочитать в полтора раза больше, чем отдельно IT Ops и в два раза больше -- чем отдельно NetOps :-)
    Ответ написан
    4 комментария
  • Сколько времени потребуется, чтобы стать веб-девелопером?

    inoise
    @inoise
    Solution Architect, AWS Certified, Serverless
    1. Все субъективно. У каждого свои способности к самообучению
    2. Вышка для программиста не является приоритетной. В некоторых направлениях помогает математика и статистика.
    3. Если вы считаете что программирование это не вредно для здоровья то вы просто не знаете о том какие профессиональные болячки в it. Их валом)
    Ответ написан
    3 комментария
  • Сколько времени потребуется, чтобы стать веб-девелопером?

    IonDen
    @IonDen Куратор тега IT-образование
    JavaScript developer. IonDen.com
    Почему вы хотите стать именно веб-девелопером? ИМХО в веб разработке сейчас такой разброс технологий, что можно потеряться. Если нахвататься по верхам HTML, CSS, JS, PHP - то вы скорее выйдете на уровень массового изготовления веб-сайтов на вордпрессе (очень нудная работа с очень высокой конкуренцией).

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

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

    Профильное высшее образование не критично (разве что вы захотите иммигрировать в страну где его требуют). Но если есть возможность учиться без ущерба для текущей работы и личной жизни - вперед. В обычном поиске работы (тем более в России) вообще не спрашивают. Главное показать работы, GitHub с проектами, т.е. показать скилл.

    Сидячий образ жизни накладывает отпечаток + туннельный синдром + позвоночник + глаза))) не все так гладко.
    Ответ написан
    2 комментария