Задать вопрос
  • Почему говорят что jquery не нужен?

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

    В любом приложении очень важно прозрачно и понятно управлять состоянием, очень желательно делать это централизованно. Былой подход с участием jQuery делает это невозможным. Кто угодно может менять что угодно на странице, когда угодно, и приложение об этом ничего не знает без очень хитровыдуманных методов. Например в первом ангуляре для этого постоянно бегал по элементам и проверял что там изменилось, это называется "грязные проверки" (dirty checking). Мягко говоря это ни разу не оптимальный способ контроля состояния, но, на тот момент, вариантов особо не было.

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

    В каких-то простых страничках с парой-тройкой функций jQuery даже сегодня может быть актуален, особенно если приложить усилия и делать грамотно.

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

    IvanTheCrazy
    @IvanTheCrazy
    Да все хорошо на апворке, ищите внимательнее. Из заказа на fix-price стоимостью изначально $3k может спокойно вырасти $30k - на практике часто сталкивался с тем что постят только небольшую часть задачи, а по факту работы вагон и маленькая тележка. Да, возможно вы неделю-две потратите на поиск подходящего проекта, зато потом сможете надолго об этом забыть. Я около года назад получил 2 проекта (один на $10k, второй на $3k). Так вот по второму бюджет в разы превысил изначальный, я съездил за счет заказчика к нему в офис в Осло + он сам приезжал ко мне в Самару и до сих пор конца и края проекту не видно - постоянно появляются новые задачи. Так что все там есть :)
    Ответ написан
    2 комментария
  • Поиск заказов. Как вы находите что-то достойное?

    deemytch
    @deemytch
    linux root, ruby/perl programmer, sql, backend.
    Скажу по секрету, что заказчики сами не в восторге от индусов. Но они везде. Это не национальность, а способ мышления. Поэтому хорошие заказы всегда отдаются тем, "кого я знаю". А бросовые - "наймём с улицы".
    Вывод: надо стать своим.
    Ответ написан
    Комментировать
  • Поиск заказов. Как вы находите что-то достойное?

    vicodin
    @vicodin
    Имею некоторый опыт
    Работы валом, бери и выполняй, дешевые заказы просто игнорируй. Также, процентов 70 от общего количества ГОДНЫХ проектов invite-only, так что, раскачивай профиль, потом будешь с инвайтов работу набирать, а не из ленты.
    Ответ написан
  • Поиск заказов. Как вы находите что-то достойное?

    opium
    @opium
    Просто люблю качественно работать
    Могу поспорить что я Сейчас зайду на апворк и найду хорошую работу для реакта или другого жс фреймворка. Может вы просто ленитесь
    Ответ написан
    2 комментария
  • Поиск заказов. Как вы находите что-то достойное?

    @Babich_S
    Многие серьезные заказчики не выкладывают задание в открытую чтоб не иметь дела с десятками заявок от кого попало, а ищут самостоятельно по профилям фрилансеров и предлагают оффер самостоятельно тому чей профиль понравился. Заработайте вашему профилю хорошее портфолио и хорошие предложения не заставят себя ждать. Хотя конечно чтоб заработать портфолио опускаться до копеечных заданий тоже не стоит, иначе такое только и будут предлагать.
    Ответ написан
    Комментировать
  • Поиск заказов. Как вы находите что-то достойное?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    Серьезные заказы никогда не приходят сразу. Никто не доверит что-то солидное новичку без вменяемого и большого портфолио и высокого рейтинга.

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

    Плюс всегда нужно стараться повышать свои шансы максимально. Учить английский, пилить свои проекты для портфолио, пытаться попасть на серьезные биржи вроде Toptal.com и т.д.
    Ответ написан
    7 комментариев
  • C чего начать изучение JavaScript опытному верстальщику?

    @s-jet
    В первую очередь нужно хорошо понимать JS, именно не выучить, а понимать. Область видимости, наследование, контекст, замыкания. Типы данных, как с ними работать. Потом разобраться с ES6. https://learn.javascript.ru/ в этом плане как оглавление, дальше по всему интернету искать статьи и видеокурсы на ютубе, главное брать и самому делать примеры из статей без подсказок и только потом смотреть готовое решение и сравнивать. Консолить, консолить и консолить. Дальше, когда разберетесь с чистым JS, учить уже фреймворки React, Angular, Vue
    Ответ написан
    Комментировать
  • Необходимые знания JavaScipt?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Идешь на сайт Кантора и штудируешь все подряд. Так же находишь на ютубе Зоракса и штудируешь все подряд. Если владеешь английским, можно еще проштудировать курс JavaScript Weird Parts. потом просто ходишь на собесы, делаешь тестовые. Поначалу все собесы будешь сливать, это нормально. После каждого слива делаешь разбор полётов и пристально изучаешь то, на чем завалился. Вангую что тебе 10 заваленных собесов хватит за глаза, чтобы выкачать всю базу. Поэтому поначалу ходи на собесы туда, где не жалко слить.

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

    В общем 5% теории и 95% практики, очень много упорства, и ты в строю через пару лет. Возможно и через годик, если будешь реально фигачить по 8 часов в день.
    Ответ написан
    Комментировать
  • Как выбраться из теоретика?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Программирование напоминает сборку сложной конструкции из простейших кубиков лего.

    Раз плаваешь на 6-кью катах, значит мозг вообще пока не настроен на процесс программирования. То ли незачем, то ли еще что мешает настроиться.

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

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

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

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

    Лично я других подходов не ведаю.

    И здесь, как справедливо заметили коллеги ранее, нужно нафигачить очень много кода. Примерно 10 тысяч часов, чтобы набить руку, выработать рефлексы, поставить основные алгоритмы и структуры данных на автомат, чтобы применял на лету, вообще не задумываясь. Никакой теорией тут результатов не добиться. Мой давний наставник училменя, что пока ты не отпрограммировал минимум 3000 часов, никаким программистом ты называться даже близко не имеешь права.

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

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

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

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

    Может быть тебе просто ничего не нужно от железяки?

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

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

    З.Ы.: Если воли фигачить самостоятельно не хватает и вектора нет, найми наставника, который будет тебя направлять, курировать и выписывать волшебные пендыля от души, стабильно и регулярно. К сожалению мой опыт показывает, что большинство людей без подобной пенделемотивации подобны гордой птице Ёж...
    Ответ написан
    Комментировать
  • Как (и возможно ли) дотянуться до 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 комментариев
  • Поможете выбрать ресурс по изучению JS?

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

    Поэтому перед академией я настоятельно рекомендую на три круга прослушать под запись курсы Zorax Или JavaScript weird parts на ютубе, почитать/послушать Кантора, это раз.

    Прорешать 30-40 задачек на кодварс (я там прокачиваю некоторых своих студентов), это два.

    И вот уже после этого идти в академию, тогда от курса будет максимальный толк и отдача.
    Ответ написан
    1 комментарий
  • Существует ли "карта программиста"? Что и за чем учить?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Нет одинаково эффективного пути для всех и каждого.

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

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

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

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

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

    На первых порах, тестирование будет занимать до 99% времени и сил. Заодно подтягивается синтаксис используемых языков (вообще не важно каких), вырабатывается внимательность, концентрация, тренируется память и пр.

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

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

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

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

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

    Ах да, обложись справочниками по любому инструменту и научись быстро вникать и подхватывать необходимый минимум. Обычно достаточно на 20% владеть инструментом, чтобы решать 80% задач.

    В любом случае я за критерий истины держу платежеспособный спрос.
    Ответ написан
    3 комментария
  • Codewars - поможет ли?

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

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

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    За всю свою практику продолжительностью более 20 лет я прочитал только одну книжку по программированию, это был Фигурнов про программирование на паскале под ДОС, и это было в середине девяностых... С тех пор читаю только документацию и то по мере необходимости.

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

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

    В общем критерий истины - практика и никак иначе.

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

    Поэтому выбери себе проект, и начинай делать. Сначала будет все плохо, непонятно и вообще адский адов ад. И только если тебе хватит упорства и настойчивости, усидчивости, концентрации и везения, то, постепенно, все начнет меняться.

    Короче говоря ключевое слово тут ДЕЛАТЬ, а все остальное - лишь вспомогательные элементы.

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

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Я в начале 2000-х писал приложение для учета некоммунальных услуг ЖКХ для местного МУПа. Начинался этот проект как тестовое задание для приема на работу.

    Писать можно было на чем угодно, но на тот момент для меня лучшим инструментом казался Clipper 5.x, которым я, как мне тогда казалось, более-менее владел.

    Проблема усугублялась еще и неразговорчивостью специалистов, работу которых мне было поручено автоматизировать.

    Забегая вперед скажу, что автоматизация, в конце концов, удалась, из режима работы 3 человека по 8 часов в день 6 дней в неделю, за 6 месяцев после начала внедрения, вышли в режим 1 человек 2 часа в день 5 дней в неделю... Т.е. 3*8*6*4 = 576 человеко-часов превратилось в 2*5*4 = 40 ч/ч, КПД был увеличен в 14.4 раза.

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

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

    Далее я реализовывал эти пути как разумел и предоставлял тётушкам.

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

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

    Первые месяцы они вели двойной учет, по старинке в своей огромной бухгалтерской книге, и в программе, и программу проверяли по книге. Через 2-3 месяца они убедились, что в программе "цифры" точнее, ошибки отлавливаются быстрее, меньшими усилиями, и стали уже свою книгу проверять по программе. Через 5-6 месяцев я написал им модуль расчета и распечатки месячного отчета, и они перестали вести свою книгу, просто печатали ее каждый месяц на огромном матричном принтере.

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

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

    Ввод/редактирование данных осуществляется посредством форм, которые, в общем случае, повторяют структуру таблицы БД, за исключением случаев, когда присоединяются поля из справочников.

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

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

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

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

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

    Причем генератор грамотно отрабатывал множественную вложенность, и каждый вызываемый справочник имел полный функционал CRU (Create, Read, Update), включая фильтрацию по столбцам и сортировку.

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

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

    Для реализации этого функционала пришлось пропатчить стандартный грид TBrowse (он применяется для просмотра таблиц).

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

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

    P.S.: когда я мигрировал в веб, через некоторое время я снова вынужден был пройти аналогичный путь, в результате которого родился простенький AJAX-фреймворк на стеке PHP+Smarty+DBSimple+jQuery. Сегодня я всеми силами стараюсь от него уйти, хотя для своих задач он достаточно хорош. Был опыт, когда на шареном хостинге за 5 баксов проект на этом фреймворке со скрипом но держал 30-40 тысяч уников в сутки (после ряда оптимизаций) и достаточно хорошо был защищен от топорного взлома через SQL-инъекции благодаря DBSimple...
    Ответ написан
    1 комментарий
  • Как максимально быстро отслеживать новые проэкты на upwork?

    @hebrian_vasyl
    Веб-разработчик
    Пользуйтесь агрегаторами фриланс бирж
    Нормальные агрегаторы показывают новые проекты с задержкой до 1 минут.
    Ответ написан
    Комментировать
  • Как максимально быстро отслеживать новые проэкты на upwork?

    vicodin
    @vicodin
    Имею некоторый опыт
    Не нужно смотреть на количество поданных заявок, уже год или больше не ранжируются заявки по времени.
    Ответ написан
    4 комментария
  • Кто работает на upwork только по верстке?

    vicodin
    @vicodin
    Имею некоторый опыт
    Работаю не только верстальщиком, но некоторые проекты на чистую верстку в работе имею. Без всяких натяжек на WordPress. Конкуренция низкая, так как хороших верстальщиков на Upwork мало(по той же причине не могу делегировать свой поток заказов - просто некому).
    Сейчас верстаю за 50$/hr.
    Английский может быть начальным, но должен не быть таким, если хочется иметь хороший рейт.
    Ответ написан
    32 комментария
  • Не могу получить заказ на бирже?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Это закат WEB разработки?
    Это рассвет качества web-разработки на фрилансе !
    59d1302d86732308296040.jpeg
    1. Будут больше заказывать "под ключ"
    2. Будут чаще работать через безопасную сделку
    3. Будут работать с теми, кто прошёл тесты на знания направлений на фриланс-ресурсе.

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

    Минимум для веб-сайтов:
    1. Внешний вид (презентабельный и "рабочий" дизайн для ЦА, корректная работа вёрстки),
    2. Удобство (UI/UX),
    3. Скорость обработки пользовательских запросов сервером.
    Ответ написан
    4 комментария