Задать вопрос
  • Смог ли кто-нибудь получить работу тестировщика после прохождения популярных курсов типа GB,Skill..,YA? Насколько это реально?

    TonyHunt
    @TonyHunt
    Part-time developer – full-time geek.
    курсов типа GB,Skill..,YA?


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

    Информации для изучения на 1.5-2 года вперёд... Можно изучать до посинения. Бесплатно.

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

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

    Проходил курсы SB/YA за счёт компании и бесплатно скачивал. Качество такое себе. В сети больше информации, доступнее рассказывается, бесплатно.

    Приведу простой пример. Ментор вещает красиво, подробно по полочкам разжовывает, пример классный придумал, проект на выходе инетересный будет. Гуглю название либы, захожу на сайт разработчика, а там... этот самый пример проекта, по шагам, с разбором, только на английском. То есть ты платишь деньги за то, что ментор нашёл материал, перевел на русский и тебе рассказывает и может на какие-то вопросы ответить. Дорогая консультация выходит однако. :)

    Насколько это реально?

    Реально. Зависит от упорства.

    Вкратце о себе, мне 28 лет, работаю манагером.

    Вкратце, мне больше 36, работал манагером, учился самостоятельно на разработчика, работаю. Доволен как слон. Со мной параллельно много было ребята 35-40, все что-то нашли.

    Повашему 28 лет, это приговор что-ли? =) Отучились и в рабство на одной работе до самой смерти? До пенсии, вы еще сможете раза 2-3 сменить ориентир, если душе будет угодно.
    Например, недавно освоил аргоновую сварку, сейчас получаю права кат С. Могу пойти сварщиком, на старте 70к+, дальше больше. Могу пойти в дальнобой, на старте 70к+. Можно взять фуру и самому катать, 130-250к в мес и так далее. Вариантов на самом деле море и много есть примеров где можно больше зарабатывать, чем в найме или программистом, или тестировщиком.

    Изучаю Python уже полгода, но чисто для себя, учусь делать боты, хочу попробовать поделать парсеры, это как хобби

    На сегодняшний день в чистом виде знание просто языка не достаточно. Нужно изучать окружение, фреймворк, соответствующие инстурменты. Если это еще и веб, то веб инструменты и в придачу базу JS.
    Одними ботами, парсерами сыт не будешь, к сожалению. Возможен вариант ботоводства, или платформы с агрегацией Х инфомрации для ЦА, но это не простая тема для джуна.

    Так как продажи уже зае...ли

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

    решил промониторить рынок и наткнулся на вакансии тестировщиков и автотестировщиков.
    что тестировщиком попроще войти в рынок it чем программистом.

    Это маркетинг. Наткнулся... Проще войти... Мало кто хочет идти в верстальщики, так же мало кто хочет идти в тестировщики. Почему? Потому что, мало кто хочет постоянно копаться в чужом коде, вылавливать ошибки.
    То, что проще, это заблуждение. Порой чтобы разрабатывать тесты, нужно знать и понимать больше чем просто программист. Потому что, нужно разрабатывать тесты (писать код), понимать специфику, разбираться в среде, знать кучу подводных камней итд.

    Типа гарантированное трудоустройство и туда и сюда. НО я же сам продажник и понимаю что никаких гарантий нет.

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

    Сколько времени это примерно у вас заняло?

    В среднем 6 месяцев, если есть какой-то бэкграунд. Если с нуля, то 1-1.5 года. Лучше найти компанию и пойти на стажировку, быстрее прокачаешься чем сам или на каких-либо курсах.

    подбором персонала "Рассматриваете ли вы реально кандидатов после курсов в возрасте от 28 лет? Вообще приходят ли к вам люди с какими то знаниями ? Даете ли шанс? Или сливаете?"

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

    на реальную работу я даже не рассчитываю.

    На реальную работу не рассчитыавет, а вопросы про трудоустройство, курсы задаёт. Странный вы тип. Разберитесь в себе. Чего вы реально хотите. Постройте план и двигайтесь к цели.

    поизучаю Pythonчик и сделаю года через полтора годика какого нибудь крутого бота

    Бот, код, продукт должен решать боль ЦА, быть полезным, а не крутым.
    Ответ написан
    2 комментария
  • Как перестать говнокодить и принимать неверные архитектурные решения?

    miraage
    @miraage
    Старый прогер
    как писать поддерживаемый код?

    Если уж очень коротко, то соблюдать SOLID/GRASP. Мне понравился твит одного из авторов React Router:
    https://twitter.com/mjackson/status/1171524189850701825

    Most common mistake software developers make: putting stuff in the wrong place. Coupling responsibilities and concepts that should be kept separate.
    For me, this is 95% of software development. Just figuring out *where* things belong.


    Что гуглить, что учить?

    Фундаментальные знания, вроде вышеупомянутых SOLID/GRASP, паттерны (не только классические паттерны, но и вообще, общеизвестные решения определённых задач), базовые структуры данных. Фреймворки/библиотеки всегда будут приходить/уходить, что-то будет забываться. А фундаментальные знания всегда актуальны.

    Может литературу какую почитать посоветуете?

    Скажу за себя. Ни одной из этих известных книжек за свою жизнь не прочитал. Писал много говнокода дома, очень много. Удалял, переписывал. Смотрел код других людей, анализировал, пытался перенять то, что считал правильным.

    Можно ли себя называть миддлом, если твой код говно?

    Не пытайтесь себя оценить. В каждой компании свои понятия миддла. А если кто-то 35 лет на лиспе кодил, а потом прыгнет на Angular - кто он, джун или сеньор?
    И, да, все мы в какой-то степени пишем говнокод. Если кто-то Вам доказывает, что он пишет супер чистый код - не слушайте.

    И ответ на главный вопрос.
    Как перестать говнокодить и принимать неверные архитектурные решения?

    Это невозможно. Все проекты, которые чуток сложнее CRUD-ов, рано или поздно обрастают говнокодом. Никто не пишет идеальный код. Код должен работать и решать проблемы бизнеса.
    Ответ написан
    6 комментариев
  • Как (и возможно ли) дотянуться до Junior JavaScript Developer в кратчайшие сроки?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Во первых: совершенству нет предела.
    Во вторых: невозможно объять необъятное и впихнуть невпихуемое.
    В третьих: как ты не крутись, а технологии развиваются быстрее, поэтому отставание неминуемо, как следствие приходится всегда чем-то жертвовать ради чего-то более важного.

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

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

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

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

    Меня на программирование пропёрло весьма рано, лет в 14-15. Я ощущал собственное безграничное могущество, послушная железяка выполняла любое моё повеление, любой мой каприз, при условии, что он правильно сформулирован. Если железка не делала что нужно, или делала что не нужно, то это всегда была моя вина, это значило что я прокосячился. Подобное осознание настигло меня весьма скоропалительно, после чего мозг начал усиленно дисциплинироваться, и количество лютых фейлов пошло на убыль.

    Коммерческая разработка - это, примерно, от 70% времени/сил на дебаг и фиксы, потому что мало где процессы поставлены грамотно. По хорошему до сего дня (а мне под 40) я только одну команду видел, где процессы прям вообще очень хорошо поставлены и мне посчастливилось какое-то время с ними поработать. За эти несколько месяцев я подрос на целую голову. Самостоятельно достичь сходных результатов было бы весьма затруднительно.

    Сам я сменил стек совсем недавно, начал в конце 15 года, и процесс продолжается до сих пор. Сменил я по одной простой причине - во всех моих прежних проектах большая часть логики с бэка уехала на фронт, и прекраснейший jQuery перестал справляться чуть более чем полностью. Он, по прежнему, хорош, но задачи, которые приходится решать, требуют совершенно других подходов. Для себя я выбрал React, но в целом на рынке имеются альтернативы. По моим данным очень большим спросом пользуется Angular 2+.

    Когда говорят о фронтенд разработке, постоянно говорят о технологиях, стеке, но почти никто не упоминает, что не стеком единым... Существенная часть разработки - это, для начала, понять задачу и построить у себя в голове модель. Заказчики бывают разные, от очень толковых, до очень безтолковых. Соотношение первых ко вторым примерно 1% и всё остальное... Т.е. в большинстве случаев тебе скажут минимум, своеобразно, плюс ты это поймёшь по своему. Потом, по ходу пьесы, в самые неподходящие моменты, начнут всплывать подробности, которые: забыли упомянуть; ну это же очевидно, ты же профи; мы сами не знали, это только выяснилось; ну это же мелочи, мы думаем тебе это будет не сложно; а ты не спрашивал; и т.п....

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

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

    Если ты попадешь в команду, где люди будут понимающие, квалифицированные, процессы выстроены, а джуну задачи будут сгружать джунские, то, считай, тебе крупно повезло. Шансов на это примерно 1%. Особенно учитывая, что джуны это обычно студенты лет в районе 20...

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

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

    Даже если тебе попадается практически идеальный проект, внезапно оказывается, что твоя оперативная память это 5-7+-2 объекта, а удерживать в голове одновременно нужно сотни...

    Зачем я все это рассказываю? Затем, что это реальность, которая для джунов не делает исключений.

    Термин "фигак-фигак и в продакшен" встречается повсеместно, т.к. ресурсы (деньги, время, кадры) практически всегда весьма жестко ограничены и ничего ты с этим не поделаешь.

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

    С другой стороны сейчас предпочитают фронта, который еще и неплохо верстает. Слава флексбоксам и современным браузерам, сейчас это делать намного проще, чем годы назад.

    Теперь относительно того что делать - если в бэкграунде нет сильных скиллов по алгоритмике и структурам данных (олимпиады по программированию, универский курс информатики), то прям очень сильно рекомендую прокачать. Будучи наставником на нескольких курсах фронтенда я постоянно встречают студентов, которые "вроде бы" знают язык, но затрудняются скомпоновать пару циклов с условиями, вот буквально просто виснут на неопределенное время, причем без результата. Лично я рекомендую кодварс. Своих студентов я прокачиваю именно там. Достаточно прорешать 30-40 задачек, чтобы базовые скиллы ушли на уровень рефлексов и перестали парить мозг. Правда желательно решать это все с наставником.

    Косвенный бонус тут будет в том, что ты привыкнешь решать задачи на JavaScript. Я когда менял стек, поначалу мыслил на PHP, и подобный финт на кодварс позволил мне переформатировать мышление на JS. Вот мой профиль на кодварс как пруф: https://www.codewars.com/users/iCoderXXI

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

    Понять надо настолько глубоко, чтобы легко и просто, с юморком, рассказывать это любой первой встречной бабушке, да так, чтобы та всё поняла... Это вот прям залог успеха в JS, потому что все остальное держится на этих двух китах. В ютубе имеется курс Зоракса (Zorax) и JavaScript Weird Parts, оба про то же самое, первый на русском, второй на инглише. Кантор, безусловно, крут, но эти двое объясняют попроще и понятнее (имхо).

    После этого прокачиваемся в использовании встроенных методов JS, таких как map, reduce, includes, replace и пр. (на том же кодварс)

    После этого нужно прокачаться в ES6+, стрелочные функции, let/const, деструктурирование, рест оператор, классы, промисы, генераторы, async/await, декораторы - без этих продвинутых штук в современных фреймворках ловить нечего.

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

    Потом уже заостряемся на API форм, DOM, AJAX (fetch/axios), вебсокетах, Localstorage и пр.

    И вот только теперь можно переключаться на фреймворки. Проще всего освоить Vue (по слухам), наибольшим спросом пользуются React и Angular, для общего развития так же неплохо бы немного послушать про Ember.JS.

    React только на первый взгляд выглядит простым, на самом деле это только view-библиотека, а в любом нормальном SPA есть много чего еще кроме view, поэтому React всегда идет в компании Redux, Router, и еще целой толпы всего, что тоже придется осваивать, не только с точки зрения API, но и с точки зрения философии (а нахрена оно вообще сдалось?)

    Перед походами на собесы очень желательно иметь портфолио из нескольких готовых проектов, вылизанных стилистически.

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

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

    Еще вроде большие компании вроде Яндекса устраивают летнее обучение, с последующим трудоустройством лучших кандидатов, но это не точно.

    Оптимистичный прогноз - 6-12 месяцев плотного фигачинга и ты в тренде.
    Ответ написан
    7 комментариев
  • Есть ли хороший актуальный на 2019 год ресурс по react/redux?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Надо просто понять суть, понять как работают HOCи (компоненты высшего порядка) и проекция props. Если совсем коротко, то ридакс - это единый стор, который не позволяет менять данные напрямую, вместо этого нужно диспатчить экшены, которые пробрасываются в редьюсеры - чистые функции, задача которых на вход получить текущее состояние стора и экшен, произвести изменения, не затрагивая текущее состояние (иммутабельно) и вернуть новое состояние. Редьюсеры вызываются по цепочке, так же по цепочке вызываются и миддлвары, которые позволяют перехватывать экшены и, например, производить асинхронные действия, вроде запросов к API. Ну и напоследок любой компонент может подписаться на изменения в сторе посредством HOC connect из пакета react-redux.

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

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

    reselect и immutable это как специи, позволяют существенно оптимизировать работу приложения, но на первых порах можно жить и без них.

    ЗЫ: Если найдешь меня в скайпе, можешь позадавать вопросы. :)
    Ответ написан
    Комментировать
  • QA engineer, с чего начать?

    @azShoo
    Для начала давайте разберемся, что же такое QA? Понятие это довольно абстрактное, и в СНГ применяется зачастую в ином понимании, нежели в краях более отдаленных.
    QA - это обеспечение качества продукта, причем, в идеальном случае, на всех этапах разработки.
    Самое первое, с чем придется в большинстве случаев столкнуться QA Engineer`у это функциональное тестирование.
    Написание тестов по задачам и прохождение этих тестов., прохождение уже написанных, апдейт, заведение багов и прочее. В этом случае QA Engineer = Тестировщик. Для этого самое важное - хорошо работающая голова, умение читать задачи и задавать правильные вопросы: "А что если так? А если этак?".
    В зависимости от продукта требуются дополнительные скиллы -> в вебе своя специфика, в мобильных своя, в по - своя, в железе - своя. Ну и соответственно базовое понимание кода, работа с базой данных и прочее - тоже периодически понадобятся.

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

    Отдельная часть - автоматизация тестирования. Здесь от компании к компании все по разному, и роль автотестера варьируется от "тестера который научился использовать тестовый фреймворк" до "полноценного разработчика, который автоматизирует то, что ему говорят тестировщики".
    Требования отличаются соответственно.

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

    Что в итоге?
    Мне кажется, что QA-инженер это тестировщик, который вышел в своей работе за рамки тестирования. Который работает над качеством продукта не только в плане "Требования выполнены - к продакшену готовы", а старается делать продукт лучше во всех отношениях, в первую очередь - для бизнеса, во вторую - для пользователя, в третью - для тех, кто этот продукт делает.
    Следовательно, я считаю что путь QA лучше всего начинать именно с тестирования (кстати говоря, в России понятия QA и тестирования почти всегда тождественны в умах не-тестировщиков).
    Что важно для тестировщика?
    Способность и желание разбираться в том, как это [продукт\фича\пр] работает сейчас, и как это должно работать.
    Так же стоит приготовиться много говорить "нет, так не пойдет" менеджерам и разработчикам.
    Ну и вообще, смириться с тем, что другие стороны процесса очень часто готовы действовать в ущерб качеству.

    Что хотят, что бы знал джуниор?
    1) представление о процессе разработки. Этапы, когда пора тестировать и все такое.
    2) представление о написании тестов: что представляет из себя тест-план, тест-сьют, тест-кейс, тест-степ, Definition of Done, Ожидаемый результат и тд.
    3) представление о том, что такое дефект: Severity и Priority дефектов, какие бывают; из чего состоит описание дефекта, и все такое.
    4) хотя бы общее представление о тест-дизайне: что такое, зачем нужен, какие есть практики.
    5) Базовые навыки SQL - селект, упдейт, работа с несколькими таблицами и все такое.
    А ещё хотят, что бы человек умел думать. Будь готов к задачкам на логику (которые туфта и ненужны) и к задачкам типа "Есть окно с кнопкой, посылает запрос: напиши тесткейсы" или "Протестируй карандаш".

    Как-то так.
    К сожалению, больше рассказал именно о тестировании, чем о QA в целом. :)
    Ответ написан
    2 комментария
  • Переход из С++ в PHP?

    Zifix
    @Zifix
    Barbatum
    На самом деле работы хватает на любом языке, не говоря уже о С++. В отдельно взятом городе может и не быть, но при наличии интернета это не особо важно. Другое дело, что найти ее не фрилансе не так просто, и среди технарей не очень многие умеют правильно продавать свои навыки напрямую заказчику.
    Ответ написан
    Комментировать
  • Photoshop, notepad++ и бочка кофе в придачу, что ещё поможет верстать сайты быстрее и с меньшими затратами нервов?

    @ferdasfarmazone
    Верстальщик!
    хм..не знаю, как кто, но зачем перезагружать страницу после каждой дописанных пару строчек кода?
    я, например, могу сразу написать html-разметку, потом ~90-95% CSS-кода, а потом через devtools в хроме подгоняю под perfect pixel.
    а так, для "быстрой" верстки советую вам скачать SublimeText3, установить следующие плагины:
    - Emmet (для быстрого написания html,css);
    - Tag (для изъятие классов с выделенного участка кода).
    Ответ написан
    Комментировать
  • Как реализовать быстрый поиск в массиве объектов по значению свойства?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Обходить миллионные массивы при каждом чихе - это жесть.

    Необходима индексация!

    Создаем отдельный массив, ключами которого будут города, а значениями - массивы с ссылками на элементы исходного массива. Таким образом все записи с определенным городом будут доступны одной простой выборкой по ключу из индекса.

    Если исходный массив постоянно меняется, то в прототип необходимо добавить функцию, которая будет отслеживать эти изменения и обновлять индекс.
    Ответ написан
    Комментировать
  • Как реализовать быстрый поиск в массиве объектов по значению свойства?

    27cm
    @27cm
    TODO: Написать статус
    Проиндексируйте значения для двоичного поиска. Создайте отдельный массив, в котором храните отсортированные значения city и номер объекта в исходном массиве.
    Ответ написан
    Комментировать
  • Как развиваться начинающему web-разработчику?

    Коротко
    Карта развития Web Разработчика

    Демагогия
    Не переживайте, не все сразу. Есть вещи до которых можно дойти только опытом и практикой. Это касается всех программистов в целом. Касательно веба, тут очень много упирается в то, каким именно специалистом вы хотите себя видеть в будущем. Есть фулстак - когда человек знает большую часть технологий их связку, но всегда будет ощущать недостаток тонкостей на хай левеле. В то же время специалист заточенный под определенные задачи будет лучше фулстака, но так же будет нуждаться в том же фулстаке, что бы объеденить.

    Живой пример: Есть толковый фронтендер(или бекендер по JS) пишет морду сайта на JS Фреймворке. Есть гуру бэкенда пишет API сайта. В случае с фулстаком(образно) он пишет обе задачи сам, но заведомо понятно, что он пишет это дольше и не факт что по последнему слову будет сделано.


    Что нужно для развития дальше:
    - Читайте блоги зарубежных программистов, они делают отличные архитектуры как в самом коде, так и решения в DB.
    - Фреймворки PHP и JS - чем больше их будет тем лучше. Все они ускоряют разработку. Все чаты, соц авторизации, регистрации,и прочие первоочередные задачи давно уже написаны. Вы можете концентрироваться на более важных задачах.
    - ООП тут очень спорный вопрос, на определенных этапах разработки оно решает, но когда этот уровень появляется, чаще всего прибегают к другому языку программирования и переписывают проект в угоду скорости (С++, Java, Python). Понимать нужно, поскольку фреймворки построены на этих парадигмах, но самостоятельно придумывать вам гибкие решения вряд ли придется(по крайней мере до Senior-а точно).
    - Не изобретайте велосипеды. Разбирайтесь в чужом коде(Этот навык очень ценен после "решить/найти решение любую задачу"). Любой магазин чаще всего будет написан в лучшем случае на фреймворке, в худшем на OpenCart, Woedpress - что просто идиотизм, это блоговая система БЛОГОВАЯ. из за тренда выкручивают яйца.
    - Учить английский и работать не на СНГ, Укр или места постсоветского пространства. Искать фирмы зарубежных филиалов и работать там. Поскольку так или иначе там уже работают профессионалы и знакомы с западным рынком, европейским. Там пишутся интересные проекты и появляются интересные решения.
    Ответ написан
    7 комментариев
  • Какие есть хорошие образцы сайтов на Node.js + Express, чьи исходные коды можно посмотреть в целях обучения?

    JiLiZART
    @JiLiZART
    Люблю Yii, PHP, JS, Angular.js, React.js, БЭМ
    https://github.com/Automattic/wp-calypso
    новая версия сайта wordpress.com
    Ответ написан
    Комментировать
  • Кто как делает html формы?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Я много, долго и упорно делал на jQuery+Vanilla JS сложные динамические формы, которые строил генератор по мета-данным.

    После одного особо зубодробительного проекта, где в форме была куча нелинейных зависимостей (интеграция потоков данных для циан и внутренней CRM заказчика), когда через некоторое время зависимости нужно было изменять в виду изменившихся условий работы, я познал боль. :)

    К тому же прямые манипуляции на DOM для меня стали еще большим злом.

    В общем от jQuery как основного движка на фронтенде я отказался категорически, сейчас плотно изучаю React+Redux и ище с ними, предварительно проведя исследования по основным мейнстримовым фреймворкам и библиотекам для фронтенда.

    Мне зело симпатишна идея рулить состоянием, а чтобы интерфейс при этом выстраивался автоматически.

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

    В совокупности с ES-2015 это всё становится приятнее и интереснее.

    Да, безусловно, есть там и свои проблемы, тем не менее прогресс не стоит на месте.
    Ответ написан
    Комментировать
  • Какие есть хорошие образцы сайтов на Node.js + Express, чьи исходные коды можно посмотреть в целях обучения?

    @yociyavi
    Всем известный learn.javascript.ru написан на ноде и опен сорс. Код можете глянуть здесь: https://github.com/iliakan/javascript-nodejs

    P.S. сам код не смотрел, но думаю его не глупный человек писал :)
    Ответ написан
    1 комментарий
  • Как верстать с использованием ReactJS?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Суть React заключается в том, что его архитектура базируется на компонентах. Как в лего, все собирается из кирпичиков.

    Далее компонент самого верхнего уровня рендерится в некоторый элемент на странице. Разные компоненты можно отрендерить в разные элементы, никто этого не запрещает.

    Так же надо отчетливо понимать, что философия React - генерировать разметку динамически при изменении стейта (состояния). Классически стейт хранится локально в каждом компоненте, однако зачастую это неудобно, поэтому придумали Flux, одной из инкарнаций которого является, в некотором приближении, Redux - некое централизованное хранилище стейта, с плюшками и балеринами.

    Насколько мне известно, React не навязывает никаких парадигм и прекрасно совместно уживается на одной странице с чем угодно, так-что, в принципе, отреактить можно только самое необходимое, а остальное запилить по старинке...
    Ответ написан
    Комментировать
  • Кто как делает html формы?

    @jaxel
    Не использовать фреймфорки в 2016 году - значит говнокодить. В symfony 2/3 отличный модуль для работы с формами.
    Ответ написан
    3 комментария
  • Как считать пустым элемент даже с пробелами?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Я отказался от прямых динамических манипуляций в DOM посредством хоть jQuery, хоть Vanilla JS. На мой взгляд это зло, которое ведет к полной и тотальной непредсказуемости поведения приложения и формированию обширного поля для неуправляемых багов.

    Наш путь - React.JS, когда интерфейсы генерятся из данных, а ты меняешь только данные.
    Ответ написан
    Комментировать
  • Ресурсы на углублённое изучение JavaScript с примерами?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Такой вид деятельности человека, как разработка программ, состоит из нескольких составляющих.

    Язык программирования - это инструмент, как молоток. Можно гвозди забивать, а можно по пальцу себе стучать, или на ногу уронить, ну и масса еще менее конструктивных способов применения.

    Вот допустим ты раздобыл инструмент и даже пару гвоздей забил им. Хорошо. Теперь перед тобой стоит задача построить сарай, и ты, вдруг, понимаешь, что кроме забивания гвоздей нужно еще кое-что:
    1) Нужно определить место, где будет построен сарай
    2) Нужно определиться с размерами сарая
    3) Нужно набросать некий план устройства сарая (гайдлайн/проект)
    4) Нужно прикинуть количество и виды строительных материалов
    4.1) Допустим строим самый простой деревяный сарай:
    4.1.1) Нужно посчитать брус под опоры (каркас)
    4.1.2) Нужно посчитать облицовочный брус
    4.1.3) Внезапно сараю нужны ворота
    4.1.4) Так же сараю нужна крыша, так-что в пункт 4.1.1 внезапно добавляем брус под каркас крыши
    4.1.4.1) Крышу решили облицовывать шифером, так-что закладываем шифер, предварительно посчитав площадь покрытия
    4.1.5) Оказалось что с земли строить сарай не удобно, нужна лестница
    4.1.6) Брусья оказались весьма тяжелыми, так-что нужна либо лебедка, либо помощники, а лучше то и другое сразу
    4.1.7) Опоры оказывается нужно заглублять в землю на полтора метра, иначе получается неустойчивая конструкция - пришлось озаботиться выкапыванием ям под опоры. Ломом это делать оказалось долго и муторно, да и лом пришлось приобрести
    4.1.8) Сосед подсказал, что если просто закопать опоры, то они сгниют за два года. Нужно опоры просмолить. пришлось купить бочку смолы и соорудить печь, чтобы смолу разогреть.
    4.1.9) Гвозди сотки забивать в доски и опоры простым молотком оказалось неудобно, пришлось приобрести молоток помощнее, но он оказался тяжелым и руки быстро устают. Работа идет очень медленно
    4.1.10) Сосед подсказал крепить доски саморезами. Пришлось купить саморезы и шуруповерт
    4.1.11) Аккумулятор у шуруповерта оказался слабый, он 10 минут работает и полтора часа заряжается. Пришлось купить еще один, работающий от розетки
    4.1.12) Второй шуруповерт За пол-часа разогревается так, что рискует расплавиться. пришлось купить еще одиин и работать ими попеременке
    4.1.13) Вот сарай построен, ворота установлены, оказалось что на ворота нужен замок
    4.1.14) Еще в сарае очень темно, пришлось провести туда электричество, для этого пришлось вкопать пять столбо ви приобрести 200 метров кабеля, и прочую электрическую мелочь типа выключателей
    4.1.15) По дереву монтировать проводку необходимо внавес, чтобы кабель не контактировал с деревом, пришлось заморочиться
    4.1.16) Зимой сарай оказался очень холодным, дерево промерзает и сыреет. Пришлось задуматься об утеплении сарая снаружи, но это летом, пока терпим.

    Ну и так можно проодлжать до бесконечности.

    А теперь, внимание, вопрос - а при чем здесь вообще молоток?

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