Gregory House

Не надо спрашивать HR и рекомендаций сервисов!
- напишите о своих навыках в описании о себе максимально подробно — это главное поле, остальные миллион полей -- полная дичь
- напишите 2-3 места работы с описанием релевантных задач (не протокольного формата, а просто — что делали)
- постарайтесь обойтись без местоимения "я" и без эпитетов (без единого чтобы вообще)
- поменьше галиматьи про "выберите навыки из списка", меньше про длинные названия университетов и курсов... меньше про личный спорт и хобби — это все фишки сервисов не нужные... вот список того, чем пожертвовал ради хорошего описания, которое не затеряется в куче полей:


...

P.S. спрашивать кадровиков, это как спрашивать девушку "какие парни тебе нравятся" они говорят "умные и спелые", а по факту выбирают нахрапистых и наглых или смазливых или вообще фиг поймешь как... также и тут, делайте хорошую презентацию без советов кадровиков (но с моими советами :)

PS>S. Распространяйте резюме эффективно, вот описание как искал работу через vc.ru

Советую хорошо подумать, правильно ли выбрал сферу деятельности для кардинальных перемен. В it 26 лет - это уже внушительный возраст для входа, кто бы что ни говорил. Не слушай студентов на тостере и онлайн-коучеров, а для начала посмотри такое мнение и такое (и другие ролики). Если ты не ссышься кипятком от вида кода, и не вскакиваешь в 5 утра, чтобы быстрее сесть программировать, то минусов в этой деятельности может оказаться куда больше, чем плюсов. Ну и вообще, чтобы сбить флёр романтики тыц и тыц.

Стоит отметить, что в ближайшие 10 лет возникнет переизбыток "айтишнеков" и острый дефицит инженерных/рабочих кадров. Соответственно, с первыми произойдет то же, что и с бухгалтерами/юристами/экономистами/риелторами, а вторые будут нарасхват и высокооплачиваемыми. Инженеры советской закалки уйдут, а техносфера никуда не денется, и станет куда более горячей сферой, чем сайтики и мобильные приложухи.

Если охота не отбилась, то нужно определиться со сферой - энтерпрайз (c#, java), мобайл (java, swift, kotlin и т.д.), web-разработка (а там либо фронтенд - html, css, туча js-фреймворков, либо бэкенд - php, python, ruby, node.js и также туча фреймворков). А может и вовсе администрирование серверов, devops, big data, машинное обучение, статистика, системная аналитика, gamedev и пр. По каждой нише свой огромный технологический стек, которого хватит на годы только изучения...потом годы вырастания из джуниора, потом годы закрепления в мидлах, а потом до свидания, потому что 25-летних синьоров на улице очередь стоит))

От того, что ты взял первые 3 языка из топ-2017 толку мало (java куда дел тогда?). На полноценное освоение (прежде чем к полноценной работе приступать), нужно минимум 2 года потратить активного набивания шишек (и не час-полтора после работы, а с утра и до вечера). Пройди курс "основы программирования на языке X", и сразу двигайся по выбранной нише, нет смысла залипать на C/C++ если нет конкретной цели их приложить к чему-либо.

Если тебе "для души" - то пробуй всё, на что глаз ляжет, и выбирай на практике, а не по советам с форумов. Если нужно поскорее на работу выйти, основной спрос на джуниоров идет в java, web (как правило, вёрстка, php и cms), 1С. На фрилансе главенствует web-разработка, в основном js на фронтенде и php на серверной части. Чтобы понять, за что браться, достаточно открыть хх.ру, биржи фриланса и изучить спрос.

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

Правильно заметили, что есть люди-исполнители, а есть люди-генераторы идей. Нужно реально взглянуть на себя и...принять это. Быть профессиональным исполнителем гораздо кошернее, чем быть генератором провальных идей. По статистике, 9 из 10 стартапов провальны...зачем пополнять собой этот список? Если ты - рыба, то многого ли ты добьешься от фрустрации по поводу неумения залезать на дерево?

Самый верный путь к рабочей идее:
1. Проработать в какой-либо сфере достаточное количество времени;
2. Познать её изнутри на собственной шкуре;
3. Выявить в ней боли/проблемы/недостатки;
4. Решить их с помощью прикладного навыка (программирования);
5. Обкатать в собственной работе;
6. Упаковать решение и реализовать коллегам по сфере;
...
7. PROFIT!

Далее...даже если завтра в голову залетит рабочая идея, готов ли ты её реализовать? У тебя есть команда, готовая работать минимум полгода-год бесплатно на время создания беты, тестов, обкатки, раскрутки? Она сможет действительно реализовать всё как надо? Если нет команды, имеются ли у тебя средства на зарплатный фонд хотя бы для 5 человек на эти полгода-год? А с учетом налогов и отчислений (+30% к зарплате на руки)? У тебя есть условия для работы этих 5 человек? Есть ли у тебя сумма на маркетинговое исследование твоей идеи (или лучше облажаться на авось)? Есть ли у тебя хотя бы миллион на первичный трафик из директа? Или надеешься донести свой стартап до пользователей путём емэйл-спама?)) Я не указал и доли того, что потребуется для реализации небольшого web-сервиса, даже при наличии действительно рабочей идеи. Может быть, идеи не прут именно потому, что ты просто не готов к их реализации, и неча порожняка гонять?)

Как выглядит стартап глазами романтичного юноши, начитавшегося глянцевых историй успеха:
1. Придумать гениальную идею;
2. Закодить в гараже в одну харю или в паре с дружбаном;
3. Разместить на сервере и получать от мира благодарности, признание и мешки денег.

Как выглядит стартап на самом деле:
1. Пахота минимум 10 лет в одном направлении/сфере;
2. Наработка профессионализма, идей, контактов, связей, клиентской базы, понимания всех нюансов сферы;
3. Угон базы, угон клиентов на себя, переманивание лучших коллег/сотрудников, оформление юрлица, открытие "своего дела" на рабочей идее)))

К примеру, "икона стиля" стартаперов - Павел Дуров, он идеолог? Нет! Прикол в том, что он именно стырил рабочую идею (также, как тырят клиентскую базу у работодателя), собрал команду, создал для неё условия, привлек корешей-евреев с еврейскими ресурсами, бюджетами и влиятельной питерской крышей, и обеспечил этому всему грамотный проект-менеджмент и маркетинг. Дело в идее? Нет, дело в реализации:)

А если серьезно, сайт - это просто промо-материал, как билборд, только интерактивный и в интернете. Языки веб-разработки - такие же инструменты, как молоток для изготовления билбордов. Веб-разработчик - нифига не носитель уникальных знаний (который просто обязан повторить успех Цукерберга, иначе не тру), и всего-лишь современный слесарь, изготавливающий технологичные интерактивные промо-материалы. А теперь представь слесаря, который завидует предпринимателям, которые заказывают у него билборды, и вскидывает руки к небу с криком "Доколе??")) Смешно? Смешнее только реплики других слесарей на тему "если нет идей, значит меняй профессию"))

P.S. Понимаю, что вряд ли отметишь мой ответ решением, ведь тебе хочется подбадриваний вида "Не сдавайся! Ищи и обрящешь! Не опускай руки и всё получится! Вот тебе ссылочки, вот тебе инструкции!", а не режущей глаза суровой реальности. Но в некоторых случаях действительно полезно осознать своё место в пищевой цепочке - антилопа или гепард, слесарь или архитектор, промо-изготовитель или промо-заказчик и т.д. И исходя из этого уже взращивать свои амбиции, комплексы и фрустрации. Повторюсь - в стремлении стать самым крутым слесарем нет ничего постыдного, и даже в финансовом плане может оказаться куда выгоднее и стабильнее других амбициозных вариантов.

Вообще вики можно для начала, а потом уже углубляться в литературу. Вот вам кратенькое описание, цель которого больше предоставить ключевые слова для поиска.

Модульные, они же юнит тесты, предназначены для тестирования отдельных модулей/классов. Суть их в том, что мы тестируем поведение только одного класса за раз. Если класс ссылается на инстансы других классов - мы их мокаем. То есть подсовываем им фэйковый класс, который имеет тот же интерфейс, но внутри не реализациа методов, а проверка, вызывали ли метод, с каким аргументами, сколько раз вызывали и т.д. Так же методы мока могут возвращать стабы (заглушки), какие-то захардкоженные под какой-то кейс данные. То есть если мы пишем класс по работе с базой данных, сокет-сервер и т.д., нам стоит соединение с базой, сокеты и т.д. оборачивать в классы, что бы можно было потом подменить на моки это добро. Если у вас в юнит тестах идет реальная работа с файловой системой или что-либо в этом духе, то это уже попахивает интеграционными тестами. Подробнее можно почитать в документации к phpunit. Так же есть такая методология разработки как TDD, советую почитать "Экстримальное программирование" Кента Бэка в этом ключе.

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

Интеграционное тестирование - тестирование нескольких модулей в связке. То есть мы тестируем наш компонент или его самодостаточный кусок в реальных условиях. Если этот компонент для работы с файлами - разрешаем ему доступ к файлам. Если база данных - то даем реальное соединение с базой. А можем что-то и замокать. Это как говорится, зависит от задачи. Скажем обращение к сторонним апишкам стоит мокать и стабить. Главная цель этих тестов, удостовериться что модули вместе работают хорошо. Особенно важно это когда модули пишут разные люди.

Функциональное тестирование - это тестирования всего приложения в сборе. Если это REST API, то у нас через curl дергаются реальные методы, отправляются более менее реальные запросы и валидируются ответы. Если web-страничка, то это UI тесты с силениумом/phantom.js/zombi.js или, если нам не нужно еще и js тестить, просто curl + какой виртуальный браузер на том же php. Вообще по хорошему функциональные тесты не допускают никаких моков и т.д. но опять же если очень хочется то можно (опять же обращение к сторонним сервисам, контроля за которыми у нас нету).

Но реалии таковы, что UI тестами покрывать проект не слишком удобно. Вопервых UI может меняться, а поддерживать их так же нужно. Во вторых это скучно. В третьих тесты могут просто падать... вот взяли и упали. И потом начинается, так, тесты опять упали... что там упало? А, не страшно, можно релизить. Так же на больших проектах UI тесты отрабатывают долго, очень долго, некоторых их просто ночью гоняют. Толку от тестов при таком подходе не слишком много, ибо разработчику стоит знать о том что что-то сломалось как можно быстрее. А так он приходит, видит что тесты опять красные, чинит эти красные тесты, и запускает... ждет... проходит пол часа к примеру, и где-то в другом месте отвалилось... Короче сами понимаете.

Приемочное тестирование - по сути те же функциональные тесты, но подаются в контексте фича-спеков. Если вы работали когда-нибудь с QA отделом, то возможно слышали про такие штуки как acceptance criteria. То есть это тот чек лист, который должен проверить тестировщик что бы удостовериться что все хорошо. На основе этого чек листа можно написать функциональные тесты. Так же есть инструменты вроде Cucumber/Behat, которые позволяют писать спецификации в виде стэпов. В этом случае спецификации для этих инструментов могут писать QA а вы просто имплементите для них степы. То есть уменьшается прослойка между "acceptance criteria" и готовыми к выполнению тестов. Более того, стэпы можно реюзать, комбинировать, масса стэпов есть готовых, вам же необходимо только предоставить стэпы подготвалливающие систему (загрузка/генерация фикстур и т.д.). Короче лепота и удобно. Но медленнее интеграционных, зато не такие жесткие как функциональные, за счет этого их проще поддерживать. QA пишут спеку, реализуем тесты под эту спеку, пишем код под тесты, тесты зеленые - функционал готов.

Ну и есть еще всякие термины типа пирамида тестов и т.д. Мол лучше много юнит тестов, чуть поменьше интеграционных и мало функциональных. Тогда тесты выполняются быстрее, а покрывать все и вся функциональными тестами обычно перебор.

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

Короче почитайте про TDD и ATDD (можно и BDD затронуть, но тут не только от программиста зависит, менеджеры, заказчик или продукт-оунер тоже должны быть вовлечены, по сути этот подход хорошо работает в рамках продукта какого-то, на фрилансе и в аутсорсе редко можно встретить) , Continious Integration и Continious Delivery.

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

Я бы картинку нарисовал, но там очень уж нецензурный вид получается ;-)

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

Уже сейчас чтобы тебя считали верстальщиком/программистом/фронтэндером/бэкэндером - надо знать в 2 раза больше технологий, чем 2 года назад. Этакий Закон Мура наоборот. Да вы сами просто посмотрите эти списки "компетенций"!

Читаешь список требований к "Web-программистам" и видишь, что месяц за месяцем, год за годом HR-ы и те, кто там им задачи ставит, вписывают в требования все больше умных словечек, которые они сами услышали и не понимают, зачем оно им нужно и нужно ли? Все ближе и ближе ситуация подходит к "Если бы водителей принимали на работу как програм.... В 2010 году это была "шутка юмора". Сейчас это уже почти реальность.

Пример хотите?

Одна государственная организация выставила список требований к "веб-программисту". При зарплате в 35000 рублей он должен уметь чуть ли не МКС программировать и чуть ли не кластера из сотен серверов настраивать. А на деле основной задачей человека будет - таскать проекторы из аудитории в аудиторию, чистить мышки студентам, переставлять winxp и изредка, раз в полгода - добавлять статью на сайт гос.организации. Откуда информация? Связался с человеком, которому 45, который в этой организации работает уже 18 лет. Ему стаж капает, а деньги он зарабатывает совсем в другом месте.

Что уж говорить об организациях коммерческих? Особенно тех, для которых веб-программист - и чтец, и жнец, и на дуде игрец?

Но это все лирика и крик души. Извините.

И да, к 35-40-45 годам по мнению "молодых и амбициозных IT-специалистов" ты должен обладать строго определенным списком компетенций как в профессии, так и по жизни (к примеру, я столнулся с отказом в приеме на позицию программиста потому что у меня нет... автомобиля. Зачем программисту автомобиль? Ну там сложная и длинная логическая цепочка, сводящася к "раз у тебя нет автомобиля - ты лох, а лохи нам не нужны").
Мне кажется, проблема в том числе и в том, что подавляющее большинство этих самых "молодых и амбициозных" специалистов совершенно не думают о своем будущем. Нет, я не про то будущее, которое "куда я пойду, когда закончу вот этот крутой проект". Я о реальности. В их понимании 35 лет - это недостижимо далёкое будущее, а до 50 они не доживут (а если и доживут - то в мечтах тимлидами в гугле).

Соответственно "молодые и амбициозные специалисты" с презрением смотрят на людей, которые отдали 15 лет разработке определенной платформы, платформы, которую сейчас тщится заменить какой-то пул новых технологий. По их мнению - все что старше 5 лет - ненужное устаревшее говно мамонта. А те, кто не знают появившуюся полгода назад технологию - отставшие от жизни ламеры.
Also, Эффект Даннинга—Крюгера тут работает в полную силу.

Резюмирую: трудно, если у тебя нет в резюме стапятисот сделанных проектов. И чем дальше - тем сложнее и труднее будет. Но тебе может повезти - если ты компетентный специалист в узкой области (даже если она 'legacy'). Или ты можешь найти синекуру - гос.организацию, в которой ты присоединишься к когорте таких же скинутых с паровоза прогресса "молодыми и амбициозными". Не переживай, через 20 лет скинут их. А ты останешься.

Вот только кушать хочется сейчас. Хотя бы просто хлебушка.

Статья старая и не актуальная. Есть новые инструменты и при чем весьма удобные.

1. Перейти на версию 8.3.6
2. Открыть доступ по OData
3. Профит.

Никаких битриксов. Драйвер есть готовый тут https://packagist.org/packages/falseclock/dbd-php

Позавчера опубликовал статью infostart.ru/public/605427

Без разницы.
Работники всякие нужны.

Нулевые не нужны конечно.
Но спецу среднего уровня - легко уехать.

Только нужно не
1. Уехать
2. Искать работу

А наоборот:
1. Найти работу
2. Уехать уже на конкретную фирму. Да и без этого рабочую визу не дадут.

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

1. Менеджер проекта организует разработку так, чтоб с доступными ресурсами уложиться в бюджет (денежный или временной) и дать на выходе работающий и качественный продукт. Для этого он в первую очередь руководит людьми, координирует сроки, внешние зависимости, определяет методики, устанавливает формы отчетности, но может и персонал набирать, и технику закупать... короче, он отвечает за все, что нужно для того, чтоб все крутилось, т.е. определяет КАК разрабатывать.

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

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

2. Для трудоустройства - как повезет, а вот для работы нужно обладать солидными знаниями и опытом во всех этих областях плюс, в идеале, глубокими знаниями технической стороны вопроса... как минимум, знать, чем отличается интерфейс от абстрактного класса ;)

3. Если это важно для продукта, то ОЧЕНЬ пригодятся, а если нет, то придется разбираться с теми технологиями, которые важны.

4. Корочка сама по себе мало кого интересует, но хотя бы общие представления о методиках управления проектами, формах отчетности, документообороте, психологии, стандартах, законодательстве и аналогичных вещах скорее всего ожидаются. Без нее (особенно если нет портфолио) велика вероятность, что у соискателя даже не было шанса узнать о существовании этих замечательных вещей, так что такие резюме часто отметают уже кадровики, и до собеседования просто дело не доходит.

5. Самая смешная часть вопроса... сначала покажите на деле, что способны заработать денег для фирмы, а потом уже задумывайтесь над тем, сколько просить за этот свой навык :)

Если надо пересчитать разово, то

UPDATE `users` 
  LEFT JOIN (
    SELECT `user_id_from`, COUNT(*) AS `count` FROM `messages` GROUP BY `user_id_from`
  ) AS `from` ON `from`.`user_id_from` = `users`.`user_id`
  LEFT JOIN (
    SELECT `user_id_to`, COUNT(*) AS `count` FROM `messages` GROUP BY `user_id_to`
  ) AS `to` ON `to`.`user_id_to` = `users`.`user_id`
  SET `users`.`sended` = IFNULL(`from`.`count`, 0), 
      `users`.`received` = IFNULL(`to`.`count`, 0)

В дальнейшем поддерживать через триггер, как написал Максим Федоров.