• Meteor.js расцветает или чахнет?

    PQR
    @PQR
    Не согласен с предыдущим оратором (@geeek), в частности с утверждением
    В общем если хочешь быть в тренде - бери
    - Meteor совсем не в тренде.

    Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

    Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

    Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
    Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

    1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

    2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

    3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

    4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

    5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

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

    Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

    Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

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

    Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
    Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.
    Ответ написан
    4 комментария
  • Что сказать верстаку который верстает так формы?

    bootd
    @bootd Куратор тега CSS
    Гугли и ты откроешь врата знаний!
    Просто не опытный! Объясните ему кто он, Вася, такой и почему это плохо!
    За свою карьеру я заметил 2 типа версталищика.
    - это тот, который смотря на макет видит в нем код в голове, целиком, видит как он будет щас его писать, где тег form, где div, а где и input. Сразу знает как верстать кастомный input file исходя из примера. Им движет опыт!

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

    @President42
    Как делается сетка: тыц, тыщ, тыдыщь

    Как делается меню: раз, два, три

    SVG: адын, два, три, четыре

    Parallax: вот, и вот, и ещё вот. И вот тут почти Parallax, думаю тоже пригодится

    Бонус:
    • JavaScript Garden -- тонкости JavaScript
    • Learn X in Y minutes -- краткие туториалы по куче языков (там и JS, и CSS и много чего ещё есть), некоторые с русским переводом (но не все)
    • Material Design -- гайдлайн по Material Design
    • PrimerCSS -- стайлгайд Github + их CSS фреймворк
    Ответ написан
    7 комментариев
  • В какой последовательности читать книги по JavaScript?

    @Aizen22
    Если дружите с английским можете посмотреть "How to learn JavaScript properly". В зависимости от текущего уровня знаний автор предлагает несколько путей изучения.
    Ответ написан
    Комментировать
  • Куда двигаться в веб-разработке?

    @rsi
    software engineer
    Перво наперво определитесь, хотите ли вы стать профессионалом или просто хорошо делать сайты. Я бы предложил выбрать путь профессионала.

    Во вторых определитесь, каким именно профессионалом вы хотите стать:
    1. web - мастером
    2. Front end
    3. Back end
    4. Desktop
    5. Другого направления


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

    Здесь вам советовали сменить язык, не слушайте этих советов. Да Ruby имеет некоторые преимущества перед php, но имеет и недостатки. Не думайте, что если вы выберите Ruby (python) ваша жизнь измениться, вы не получите ничего, что не может вам дать php и на оборот, эти увеличенные зп и прочее миф, язык не важен. Помните, ЯП это всего лишь инструмент, вы конечно должны иметь инструмент, и должны знать свой инструмент в совершенстве, но умение программировать заключается не в этом. Да, плотник алкоголик, который зарабатывает на жизнь забивая гвозди, может хвалить свой молоток и всем рассказать, что молоток его кормилец, но согласитесь настоящий строитель умеет не только гвозди мотком забивать, не говоря уже об архитекторе, который молоток и в руках мог вообще не держать.

    И так предположим, вы выбрали свой путь, вы выбрали направление и выбрали инструмент. Теперь вам нужно работать в этом направлении (как над собой, так и в буквальном смысле работать). Читайте статьи, читайте книги (я всегда рекомендую только одну книгу - "Совершенный код", ее без преувеличивания должен прочитать каждый программист), изучайте новые фреймворки, технологии, отрасль постоянно движется вперед, вам нужно двигаться вперед еще быстрее, что бы хотя бы не стоять на месте. В процессе работы над проектами вы будете чувствовать нехватку знаний (вы упоминали js, ООП), устраняйте эти пробелы книгами (не стоит бояться 900 страниц, книги вы ничем не замените, их необходимо читать), статьями и конечно практикой. Не переживайте по поводу отсутствия высшего образования, оно не дает глубокого знания, никто не расскажет вам ни каких трюков, если у вас не будет толкового преподавателя. Но толковый преподаватель, это не обязательно учитель в универе, это может быть автор книги (например Макконел), автор хорошего инструмента (например Taylor Otwell), большинство очень известных и авторитетных людей генерирует тонну информации, книги, статьи, записи в соц. сетях, код, все это можно читать и это даст вам куда больше чем ВО. И да, мы с вами живем в уникальное время, время интернета, где нет расстояний, и это дает намного больше возможностей, чем нагуглить очередной костыль для jquery от школьника, вы можете общаться лично например со Страуструпом или тем же Тейлором, ни в одном учебном заведении России у вас не будет возможности поговорить с такими людьми.

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


    Следуя этим советам вы увеличите свой скилл, сможете сами отвечать на вопрос заданный в заголовке и станете профессионалом. И помните путь профессионала, это постоянная работа (как буквально работа, так и работа над собой, если просто писать сайты 24/7 вы тоже профессионалом не станете), гораздо больше чем 8 часов в день, 5 дней в неделю.
    Ответ написан
    Комментировать
  • Как определить свой уровень программирования?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Эти уровни - абстракция, причем зависящая от компании. Пройдите несколько собеседований и спросите, что думает о вас интервьюер.

    Юниор чаще всего - это программист с в основном теоретическими знаниями, либо наоборот только практическими знаниями. Он умеет решать более-менее стандартные задачи. Юниора обязательно надо учить. При получении нового задания он "создает" свое решение.

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

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

    -----------------

    Многое зависит от интервьюера.
    У меня был случай, собеседование на php senior developer: поговорили про HL оптимизации, архитектурные предложения для решения неких задач, способы оптимизации и т.д., а потом:
    - перейдем к практике: что произойдет в таком коде:
    $a = 5 + '5abc' + 'abc5';
    - произойдет следующее: я посмотрю blame скрипта и поговорю с автором этой строчки, что бы узнать, что такого хренового в жизни может произойти, что бы он позволил себе это написать.
    - ну, тут вопрос на приведение типов
    - 10, но вы в своей практике с подобным сталкивались?
    - нет
    - вот и я не сталкивался...
    Ответ написан
    1 комментарий