• Как лучше фрилансеру (или веб-студии) получить деньги из США в Украину?

    opium
    @opium
    Просто люблю качественно работать
    вариант в целом либо через посредника, либо скажем какой нибудь payoneer
    Ответ написан
    Комментировать
  • Как добиться плавности высоконагруженной анимации?

    Ronnie_Gardocki
    @Ronnie_Gardocki
    Я у мамы фронтендщик.
    Так как я уже убитый после рабочего дня и войны с кастомными скроллбарами, то полного ревью по веб-перфу дать не смогу. Но по мелочам пробежаться могу.
    1) Вот так выглядит таймлайн сайта, после полного скролла вниз, а затем вверх (смотреть на верхний график).
    YjaRo9S.png
    Если в кратце, то все печально :) На всех переходах фпс стабильно падает до 30 (и иногда ниже). Ваша цель - 60 фпс в среднем, и не ниже 40 на паре-тройке фреймов при переходах.
    Если вы чайник в замерах веб-перформанса с помощью таймлайна (и дев тулс вообще), то вам сюда:
    а) https://developers.google.com/web/fundamentals/per... - святой грааль.
    б) https://www.udacity.com/course/browser-rendering-o... - по сути дела дополнение к текстовому варианту, но только в виде отличных видео и мини-тестами. Там же на udacity есть похожил курс от Григорика.
    в) Искать другие годные статьи в дайджестах и блогах, пилить/изучать демки и все такое.
    2) Очень беглый осмотр показал, что у некоторых элементов анимация происходит с помощью изменения таких свойств как left например (вылезающий и жутко тормозящий блок справа на 3 странице). В 90% случаев для анимации движения/перемещения/отображения прилично использовать только transform/opacity, особенно когда речь идет о больших элементах. С анимацией всяких left/top/width и подобных вещей для больших элементов можете вообще забыть о 60фпс.
    3) Основную ставку вам надо будет делать на создание отдельных слоев для элементов, проще говоря юзать translateZ/backface-visibility. Но только юзать это надо с умом, и каждый раз все профилировать через таймлайн. В веб-перфе есть одна крылая фраза "Tools, not rules".
    Ответ написан
  • Есть ли плагин, который анимирует смену класса DOM-элемента?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    1. Вот этот инструмент позволит сделать любой блок анимируемым, максимально универсально: matthewlein.com/ceaser

    2. А дальше вы например добавляете блоку еще один класс, который например меняет left с 0 на 100 и всё, анимация сработает.

    3. И посмотрите в сторону animate.css.
    Ответ написан
    Комментировать
  • Верстют ли так? И на сколько это этично (:?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    Множественность классов — абсолютно нормально.
    Но до мышей, конечно, делиться не нужно:)
    Ответ написан
    1 комментарий
  • Где найти пример подбных «карточек»?

    mudrick
    @mudrick
    Máximo progreso hemos alcanzado en minimo seso.
    Как же бесят сайты с автоподгрузкой при прокручивании. Умники, создатели/дизайнеры сайта, вы хоть раз пробовали своим произведением пользоваться? — попробуйте прокрутить до футера, чурбаны.
    Ответ написан
    2 комментария
  • Тяжело ли, зная язык программирования на уровне джуниора, найти удаленную работу?

    Captain
    @Captain
    Если кинуть объявление, что обучаю бесплатно программированию для web с последующим трудоустройством, то начинают ломиться просто толпы народа. Результат? 99% из них пропадают через месяц. Потому что не хотят или не умеют работать и учиться самостоятельно (при оказании любой консультативной помощи). Потому что не могут заниматься периодически не очень увлекательными вещами, потому что распыляются. Так через месяц они захотят стать дизайнерами, еще через месяц фотографами и т.п.
    К чему я это говорю? Вы столкнетесь с тем же самым. Сдюжите? Самостоятельно обучаться сложно и надо иметь fun, как говорят американцы, с этого должно переть. Иначе будет фигня... Надоест все через месяц.
    Ответ написан
    7 комментариев
  • Каков путь разработчика web-страниц?

    vicodin
    @vicodin
    Имею некоторый опыт
    На сегодняшний день рекомендую книгу — она небольшая, но даёт небольшое представление о технологиях.
    Ответ написан
    1 комментарий
  • Что такое Less и Sass?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

    Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:
    • организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
    • Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
    • Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
    • Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.


    Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

    • У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
    • С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
    • Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
    • Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.


    Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

    Далее уже шли какие-то модификации дальнейшие, вроде того же Stylus, где синтаксис упростили просто до нельзя.

    Личное мнение. На сегодняшний день я не вижу смысла использовать чистый CSS хоть на малых хоть на больших проектах. Вот вообще никакого.
    Ответ написан
    3 комментария
  • Совет по поводу биржи Odesk?

    @sergikzv
    Странно все, работаете php программистом а судя по работе чистый фронтэндщик, насколько я понял вы во всем по не много нахватались и судя по зарплате у вас совсем все плохо, единственный путь вижу для вас по быстрому подтянуть wordpress и оплату не ставьте ниже 10 баксов.
    Ответ написан
    2 комментария
  • Как сделать эффект соединения кусочков изображения в одно целое?

    copal
    @copal
    𝄞 ...оооо baby
    Теоретически это должно выглядеть примерно так -
    1) отталкиваясь от размеров экрана создать нужное количество квадратиков.
    2) учитывая размеры квадратиков рассчитать для каждого координаты на плоскости и сохранить их.
    3) каждому квадратику расчитать рандомное положение на плоскости ( x, y, rotation ).
    4) задать квадратикам рандомные координаты и сохранить.
    5) подписаться на событие прокрутки колеса мыши и рассчитать сколько "анимационного времени" должно пройти за определенное значение дельты.
    5) задать анимацию движения от "текущего положения" к "положению рассчитанному на шаге 2.
    6) начать крутить колесиком и смотреть, как из рандомных координат картинка начинает собираться.
    7) после того, как она соберётся установить интервал для прокрутки колеса мыши, например в пол прокрутки, чтобы анимация не реагировала.
    8) после того, как будет преодолен установленный на предыдущем шаге интервал, начать анимацию приводящую сложенною картинку, обратно к рандомным координатам.

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

    sidorenkoda
    @sidorenkoda
    Программист, верстальщик, руководитель проектов
    Это имеет смысл, особенно, если ваши посетители имеют медленный интернет.
    Прочитать про это вы можете на примере css спрайтов - https://www.google.ru/?gfe_rd=cr&ei=U2GpVNuXIKepwQ...
    Я затрагивал эту тему в своей статье - candevelop.ru/blog_current/34.php
    Выдержка:
    Когда мы запрашиваем страницу в интернете, то одновременно с ней, зачастую, получаем кучу дополнительных файлов: изображения, стилей, скриптов. В реальной жизни сопоставим это с количеством посылок, это может быть 10 маленьких, за которыми сложно бегать или же одна большая коробка, которую быстрее принести. Для уменьшения запрашиваемых элементов и их объема применяется множество технологий: картинки склеиваются в одну, стили CSS и JS скрипты интегрируются в код основной страницы, а не подключаются отдельно.


    А в качестве инструмента, для сбора проекта в один файл очень советую вам Gulp habrahabr.ru/post/208890
    Ответ написан
    Комментировать
  • Почему многие программисты не любят javascript?

    Symphony
    @Symphony Куратор тега JavaScript
    Потому что js можно освоить за 2 недели и уже писать за еду. На обучение Java/C/C++/C# Вы потратите больше времени и усилий, а еще и матчасть, придется прочитать не одну книгу.
    Как показывает статистика тостера: чтоб быть так называемым "js-программистом" обычного javascript*a вообще не надо знать, большинство посмотрели на ютубе 2 видеоурода по жиквари и, извиняюсь за выражение, "херачат" сайты на жомле.
    Ответ написан
    2 комментария
  • Как воспроизвести аудио на html странице?

    nalomenko
    @nalomenko
    Руководитель отдела разработок в студии «Lava»
    var audio = new Audio('./sounds/sound.wav');
    audio.play();
    Ответ написан
    3 комментария
  • Куда пойти учиться?

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

    Совет: прочитайте пару книжек по PHP и JS, сделайте пару сайтов и идите на собеседование в говно-фирму по разработке говно-сайтов за говно-зарплату на должность говно-кодера. Через пол года-год если все будет ок, то найдете лучшее место.
    Ответ написан
    1 комментарий
  • Можно ли выкупить красивый IP в личное пользование и использовать его вместо домена?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    Продам 192.168.1.0. Недорого. К лотку приучен. Жрёт мало.
    Ответ написан
    Комментировать
  • Можно ли закрасить только часть фигуры (div)?

    iiil
    @iiil
    Инженер и вэб-дизайнер, рисую.
    Без дополнительных блоков внутри, используйте градиент. Не забудьте префиксы поставить для кроссбраузерности.
    codepen.io/iiil/pen/KBzvo
    Ответ написан
    Комментировать
  • Как правильно считать часы при «почасовой оплате»?

    Максимум что я выдавал в офисе, это 6ть часов, после чего был выжат как лимон, даже адекватно думать не мог. Подсле пары тройки таких дней, один-два дня уходит просто в трубу, занимался ерундой, но не работой.
    Лучше на каждые 45 минут выделяйте 15 минут отдыха (это и туалет, и чаек, и почитать). Так и считайте рабочий час.
    Можно так же добавить через 4ре часа час-два отдыха (сон, прогулка, но не обед, или перед обедом). 2 таких подхода и будет 8мь часов, и устласти возможно будет меньше
    Ответ написан
    Комментировать
  • Как эффективно переучиться на веб-разработчика?

    SazereS
    @SazereS
    Как я обычно советую людям изучать веб-технологии:

    1. Разобраться в принципах работы HTML и CSS, завести справочник по тегам/свойствам и больше к этому не возвращаться. С тонкостями разбираться лучше по мере возникновения необходимости. Вообще, всю теорию HTMLя можно уместить на двух листках А4 11м шрифтом.

    2. Изучить какой-нибудь из серверных языков: PHP, Python, Ruby, можно и NodeJS, но тогда лучше сначала разобраться хотя бы с основами JS. Причем не стоит сразу использовать фреймворки — для начала написать что-нибудь простое, типа «4 странички с текстом из базы + комментарии на них». Затем попробовать реализовать MVC на том же проекте. Сделать авторизацию, админку и т. д.

    3. Вернуться к фронт-энд части и сделать ее более динамичной — это сначала чистый JS, а потом и JQuery или Blackbone, или что вам еще понравится. Разобраться с AJAX, написать чат на нем, например. Попробовать фронт-фреймворки, LESS, SASS и т. п.

    4. Опять бэк-энд. Ставим фреймворк, к которому душа лежит, и пытаемся сделать какой-либо сложный проект.

    5. Тут вы уже сами поймете что делать ;)
    Ответ написан
    Комментировать
  • Как эффективно переучиться на веб-разработчика?

    @egorinsk
    Вообще, не увлекайтесь спецификациями. Марк Цукерберг как-то без них обошелся. Google тоже не следует строгим стандартам.

    Если вы хотите «эффективно» изучить матеиал, тогда вы должны читать статьи «для чайников» (которые вы с вашим опытом, наверняка освоите за кратчайшее время). HTML/CSS так устроены, что даже если вы сделаете 100 ошибок на странице, он все равно как-нибудь да отобразится. Ну если вы хотите более солидные знания, то параллельно смотрите непонятные моменты в спецификациях, это в общем-то полезно. А сэкономленное время посвятите практике. Она тут очень важна.

    Вот, что стоит изучить (в любом порядке):

    1) Начните с основ HTTP (только ради бога, не читайте спецификацию целиком, хватит общего представления о методах запросов, заголовках и теле запроса, кодах ответа 403/404/500/200/300)
    2) Изучите основы HTML (есть раздел на сайте htmlbook). SGML вам хватит в том объеме, в котором он упоминается в спецификации HTML. PCDATA не упоминается в ней и потому знать про отличия от CDATA вам не нужно (ну если так хотите узнать, найдите спецификацию SGML и почитайте).

    Обратите внимание, в некоторых (некачественных) статьях вы можете увидеть штуки вроде [br /] — самозакрывающиеся теги. Это ошибочный синтаксис, который употребляют авторы, путающие HTML и XHTML. В HTML такого синтаксиса нет (хотя в силу своей толерантности к ошибкам в HTML такой код как-то работает).

    3) Изучите CSS и позиционирование элементов. Вот хороший учебник, разъясняющий тонкости всяких флоатов: softwaremaniacs.org/blog/category/primer/ А спецификацию CSS2.1, думаю, вы нагуглите сами, она довольно понятно написана.

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

    5) Изучите один из серверных языков, хотя бы основы

    6) Изучите основы SQL

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

    8) Изучите ООП

    9) Изучите какой-нибудь серверный MVC-фреймворк

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

    > А есть ещё и XHTML, который тоже имеет свои отличия…

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

    > Клиентская разработка нынче редко обходится без всяких шаблонизаторов типа HAML/SASS

    Вы еще Coffescript забыли упомянуть. Это очень спорные вещи, есть мнения как за, так и против. Но в любом случае, согласитесь, как-то странно изучать SASS, не изучив вначале CSS, верно? Начинающему это не нужно.

    > а для эффективной серверной разработки всё и того сложнее: фреймворки, ORM, continuous integration, очереди задач и прочая-прочая.

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

    По вопросу, где брать информацию: авторитетные источники (для поиска ответа во всех подробностях) — это спецификации W3C, официальная документация фреймворков, неофициальные источники вроде htmlbook, stackoverflow или Хабра — для того, чтобы быстро получить представление о тех или иных возможностях HTML. Еще можете какую-нибудь книгу почитать, только не старую.
    Ответ написан
    5 комментариев