Comments 381
Под каждую технологию бы еще ссылку на курс coursearea или edX положить, было бы бесценно.
Когда это роутинг и шаблонизация на бэкенде стали извращением?
Роутинг — нет. Но когда он на Ruby, да вместе с шаблонизацией — извращение натуральное.
Бред. Это очень медленно и никто так не делает.У нас в компании именно так и делают для внутреннего использования.
Это медленно, если у вас сервер нагружен тысячами подключений. А если раз в час заходят пять сотрудников, всё весьма шустро. И отлаживать так гораздо удобнее.
В чём же извращение писать роутинг (правила роутинга) на Ruby по сравнению с другими языками?Я же написал, что нет — не извращение. Но только если роутинг. Это и будет классический бэкэнд.
А вот если делать ещё и шаблонизацию, тогда это будет изврат.
Slim и HAML — это не Ruby и даже не подмножества.
Ну да. Это шаблонизаторы для Ruby, а не надмножества. Цитата с оффициального репозитория на гитхабе проекта:
Slim is a fast, lightweight templating engine with support for Rails 3 and later. It has been heavily tested on all major ruby implementations.
в чём я сильно сомневаюсь, потому что это медленно и нерациональноЕщё раз — это медленно с точки зрения массового применения. А вот с точки зрения необходимости каждый раз запускать ребилд, при изменениях, если они вносятся часто, а посетителей у проекта единицы — это уже гораздо более рациональный подход.
Тоже не понял в чём проблема. Я вот на Python генерирую готовый html код — это быстро и надёжно.
Ну, можно и гвозди отвёрткой забивать, при желании.
Какая-то нелепая отмазка, вместо обоснования своего кунг-фу.
Подход в генерации html на сервере — оправдан скоростью и удобством.
Вопрос не в подходе, а в выборе инструмента. Можно и на ассемблере вывод шаблонов для HTML написать, при большом желании, вопрос лишь в том, что так никто не делает, потому что есть более удобные инструменты.
То же самое и про питон. Конечно, если вы больше ничего не знаете, вам удобнее будет найти для него уже готовый шаблонизатор и реализовать такой вариант. Вопрос весь в том, что по некоторым причинам, о которых я тут не брался рассуждать, на рынке вакансий именно для web сейчас больше востребованы другие языки, для которых используются другие подходы, вот и всё. Вполне допускаю что вам это не нравится.
Скорость — это нативный HTML без всякого SSR в принципе, а удобство это всё про выбор инструмента и не более.
То же самое и про питон. Конечно, если вы больше ничего не знаете, вам удобнее будет найти для него уже готовый шаблонизатор и реализовать такой вариант. Вопрос весь в том, что по некоторым причинам, о которых я тут не брался рассуждать, на рынке вакансий именно для web сейчас больше востребованы другие языки, для которых используются другие подходы, вот и всё. Вполне допускаю что вам это не нравится.
Скорость — это нативный HTML без всякого SSR в принципе, а удобство это всё про выбор инструмента и не более.
Во всехДа что вы говорите? Почитайте про подход Pyramid в вашем питоне. Или расскажите мне где, например, MVC в Backbone.js…
Это только пара примеров. Похоже вы явно лучше понимаете о чём говорите, только почему-то не видите очевидного — инструментов реально столько, что даже один подход можно реализовать совершенно по разному и никакой там «концептуальной схожести» не будет даже близко.
Ну вот я открыл документацию:
Ну вы откройте заодно то, что говорят сами разработчики про наличие концепции MVC в их фреймворке.
Вот вам цитата, чтоб вы не утруждались.
Мы считаем, что есть только две вещи: ресурсы (resource) и виды (view). Дерево ресурсов представляет структуру сайта, а вид представляет ресурс. Шаблоны (template) в реальности лишь деталь реализации некоторого вида: строго говоря, они не обязательны, и вид может вернуть ответ (response) и без них. Нет никакого «контроллера» (controller): его просто не существует. «Модель» (model) же либо представлена деревом ресурсов, либо «доменной моделью» (domain model) (например, моделью SQLAlchemy), которая вообще не является частью каркаса. Нам кажется, что наша терминология более разумна при существующих ограничениях веб-технологий.
У меня нет большого желания пускаться с вами в споры о том, что чем является, потому что продуктивного смысла в этом никакого, но авторам фрейма, когда они говорят о собственном коде, я доверяю чуть больше чем вашим потугам натянуть сову на глобус.
Начнём с того, что Backbone — это фронтендный фреймворк. И там, строго говоря, не MVC, а MVP.Ну да, про бэкэнд пропустил. И, тем не менее, это, опять же, лишь один из примеров, не вижу никакой проблемы бэкэндному фреймворку использовать MVP.
Ловкий и совсем незаметный переход от критики подхода к критике инструмента.
Причём тут SSR вообще?
При том, что в первом комментарии речь шла именно про SSR на Ruby, перечитайте.
Вероятно путаница произошла отчасти из нечёткости понятия SSR. Дело в том, что данная аббревиатура чаще подразумевает именно использование JS-фреймворков в качестве шаблонизаторов.
И, тем не менее, «классический шаблонизатор», это, по своей сути, ровно тот же SSR, просто язык другой. Ну или приведите кардинальные различния, если считаете иначе.
И, тем не менее, «классический шаблонизатор», это, по своей сути, ровно тот же SSR, просто язык другой. Ну или приведите кардинальные различния, если считаете иначе.
Slim и HAML — это именно что классические шаблонизаторы, просто для удобства в них вместо HTML используется более простой и чистый синтаксис.И что, часто такая связка используется, на фоне подхода PHP+Blade, например?
Так статистика будет, не?
Ну и будьте последовательны, давайте аналогичную для Laravel, в котором из коробки Blade для этих целей встроен.
А в Rails из коробки ERB встроенТак бы сказали сразу, вам самолюбие не позволяло излагать конкретику или просто характер вредный?
Я про встроенный шаблонизатор в Rails ничё не знал, собственно поэтому для меня всё это и выглядело странно изначально.
Я про встроенный шаблонизатор в Rails ничё не знал
Зачем писать о том, чего не знаешь?
Где я писал про Rails?
Я не буду тут рассматривать различные извращённые варианты, когда, например, Ruby on Rails используется как роутер и шаблонизатор для итогового HTML (Slim, Haml, etc.), просто знайте, что такие изощрения тоже существуют.
Так тут написано, что «не буду тут рассматривать», и, собственно, оно нигде и не рассматривается, в чём проблема?
Вас до глубины души задело слово «извращение»?
Вас до глубины души задело слово «извращение»?
Рассматривается, потому что подход Rails назван «извращением» и «изощрением», несмотря на то что сервер-сайд рендерингу в таком виде уже не один десяток лет и реализован он не только в Rails а и в вагоне других MVC фреймворков. Это утверждение вводит в заблуждение неофитов, не знакомых с Rails и другими фреймворками.
У меня бомбит от того что вы написали кучу дичи, не имея понятия о том, что вообще почем, да еще и имеете наглость спорить в камментах с людьми, непосредственно работающими с этими технологиями, и остаивать свои ошибочные утверждения.
Используете на проекте Angular? Писали на плюсах? Вот и пишите про Angular и про плюсы, а про все остальное не пишите, потому что не использовали и не знаете.
У меня бомбит от того что вы написали кучу дичи, не имея понятия о том, что вообще почем, да еще и имеете наглость спорить в камментах с людьми, непосредственно работающими с этими технологиями, и остаивать свои ошибочные утверждения.
Используете на проекте Angular? Писали на плюсах? Вот и пишите про Angular и про плюсы, а про все остальное не пишите, потому что не использовали и не знаете.
несмотря на то что сервер-сайд рендерингу в таком виде уже не один десяток лет и реализован он не только в RailsЯ уже отметил, что в данном контексте был не прав и эту часть перепишу.
У меня бомбит от того что вы написали кучу дичиЭто попытка систематизировать огромную и полностью хаотичную на данный момент область, очевидно что тут будут ошибки в нюансах.
да еще и имеете наглость спорить в камментах с людьми, непосредственно работающими с этими технологиямиОпять же, не моя вина, что «люди работающие с этими технологиями», в абсолютном большинстве случаев не пишут ничего конкретного кроме «вы пишите бред». В случаях, когда комментарий по сути и я не прав — я уточняю свои умозаключения, а статью обновляю, в чём вы можете убедиться, внимательно перечитав комментарии.
и остаивать свои ошибочные утверждения.Опять же, ваше поведение примерно следующее: «Да ты написал херню, тут нечего обсуждать, иди пиши о том, что знаешь». Пока что вы ничего по сути, кроме оскорбления меня как автора не написали.
а про все остальное не пишите, потому что не использовали и не знаетеПредлагаю вам не писать комментарии. пока не научитесь выражать свои мысли менее агрессивно, например, а пока пойти потренироваться в дискутировании с ребятами из соседнего класса.
Извините, но как я должен был изначально догадаться, что вы не знаете ничего про шаблонизатор в RailsНу вы же такой умный, вон сколько предположений уже выстроили, могли бы и до этого додуматься.
и утверждаете, что все вокруг вас беспричинно обижают, бестолково холиварятЯ подобного не утверждал. Я писал что вы лично бестолково холиварите.
Термин SSR возник и имеет смысл в контексте рендеринга и "гидрации" SPA, а не просто обозначает сборку ХТМЛ из шаблонов. Изучение технологий по аббревиатурам — расхожая болезнь юных программистов.
Признаю что неправ, если вы мне приведёте хоть одно фундаментальное различие между сборкой HTML на стороне сервера с помощью JS-шаблонизатора и формированием этого HTML с помощью шаблонизатора, написанного на любом сервеном ЯП. Кроме, очевидно, того факта, что для запуска первого нужна нода.
Чем вы (или я) фундаментально отличаетесь от квантовых флуктуаций? (Это не оскорбление, это вопрос, показывающий парадоксальную суть вашего вопроса в более сжатой форме. Ответ на него точно такой же, как и на ваш.)
Скорость сборки может иметь значение. В этом случае JS не лучший вариант.
В случае серверного рендеринга SPA-приложения (SSR) непосредственно рендеринг страницы на сервере делает тот же самый код (включая некоторую бизнес-логику), который также размещён на клиенте и может там сформировать точно такую же страницуЯ не могу понять, почему вы называете это обязательным условием.
Если мы рендерим страницу из компонентов, написанных на React с помощью JSX, на сервере, а клиенту отдаём только один раз ядро приложения и далее код нужной страницы в HTML, без кода компонентов — это, по вашему, не SSR?
Если я преобразую код компонента описанный силами JS в HTML-код, это именно рендеринг, потому что происходит выполнение JS-кода в его рантайме (Node) для получения HTML. Если же говорить, что это просто «необычный шаблонизатор», то ничего не мешает и любой «обычный» шаблонизатор называть рендерингом, поскольку чёткого различия не приведено.
Потому что эта аббревиатура возникла именно для обозначения такой технологии. Исторически. Обозначают ей именно это, а не то, что нафантазаировали вы в отрыве от проблематики, просто глядя на буквы аббревиатуры.
Потому что эта аббревиатура возникла именно для обозначения такой технологии. Исторически.Хорошо, это более здравый аргумент.
а не то, что нафантазаировали вы в отрыве от проблематики, просто глядя на буквы аббревиатурыЯ не фантазирую, а пытаюсь разобраться в том, чем это принципиально отличается от классической шаблонизации.
Как видно из приведённых выше аргументов — ключевое отличе тупо только в том, что в качестве шаблонизатора выступает что-то на JS.
Я кстати в этом не уверен, потому что употребял термин серверный рендеринг еще до того как появились реакты именно в контексте «выдача готового html сервером» vs «загрузка данных по ресту и отрисовка на клиенте spa».
Может подкинете какой пруф по поводу историчности возникновения аббревиатуры?
Может подкинете какой пруф по поводу историчности возникновения аббревиатуры?
Например отличие в том, что в случае SSR на Javascript можно передать на клиент шаблон и перерендеривать страницу без обращения к серверу, а в случае шаблонов на других языках придется обязательно ходить на сервер и рендерить там.
Вопрос не в подходе, а в выборе инструмента. Можно и на ассемблере вывод шаблонов для HTML написать, при большом желании, вопрос лишь в том, что так никто не делает, потому что есть более удобные инструменты.
Вот именно, что в выборе инструмента. Современное веб-программирование сравнимо с использованием навороченного станка с ЧПУ. Но если вам просто надо просверлить отверстие, достаточно воспользоваться шуруповёртом.
То же самое и про питон. Конечно, если вы больше ничего не знаете, вам удобнее будет найти для него уже готовый шаблонизатор и реализовать такой вариант.
Ага, и вместо сотни строчек на питоне получим проект охренительнейшей сложности. Нормальный разработчик знает несколько методик разработки и выбирает наиболее удобную для конкретного случая.
Помню, был у меня студент, который решил доработать мой проект по обработке изображений на C++. Проект был маленький, не имел зависимостей, кроме системо-зависимых вызовов. Студент же решил сделать его кросс-платформенным, подключил несколько 3rd-party библиотек. Как итог: проект раздуло до нескольких гигабайт, компиляция с нуля стала занимать десятки минут, проект перестал быть переносимым (нужно скачивать тонну зависимостей, пусть и через cmake). Да, его подход более правильный с концептуальной точки зрения, но не с точки зрения решения конкретной задачи.
Плюс ещё СЕО-оптимизация
Можно сделать целую серию материалов.
Даже заголовок оставить тем же, только менять характеристику персонажа.
Как подступиться к fullstack-разработке сегодня, если ты:
— юный смузихлеб с подворотами хотящий вайти
— проджект манагер живущий по эджайлу
ну и так далее
Даже заголовок оставить тем же, только менять характеристику персонажа.
Как подступиться к fullstack-разработке сегодня, если ты:
— юный смузихлеб с подворотами хотящий вайти
— проджект манагер живущий по эджайлу
ну и так далее
… проспал 20 лет и был электронщиком
Вам не нравится сама идея подобного материала или конкретно заголовок?
Я думаю, дилетантский подход к его составлению.
Далеко ходить не нужно: секция про css неполная. Пик популярности LESS и SASS был где-то лет 5 назад, затем вышел PostCSS. Уже долгое время существую проекты вроде jss, styled-components, emotion и прочие.
Про это и остальное в комментариях довольно развернуто описали.
Далеко ходить не нужно: секция про css неполная. Пик популярности LESS и SASS был где-то лет 5 назад, затем вышел PostCSS. Уже долгое время существую проекты вроде jss, styled-components, emotion и прочие.
Про это и остальное в комментариях довольно развернуто описали.
Когда речь заходит о том, в каком направлении проще всего найти работу, безусловными лидерами остаются три языка — PHP, Node.js и Python.
Пффф, где Java? Мой Круг — не такой большой, как hh, и я слышал что на нем сидят только ИТ компании. Андроид — это малая часть Java-разработки. Как мне кажется, Java все таки занимает большой кусок бэкенд разработки(старое тоже надо поддерживать так-то).
Вообще я согласен с тем, что Java как технология неплоха для бэка.
Но мониторинг предложений о работе явно говорит о том, что найти работу кодеру на яве сложнее, чем любому пишущему на указанной троице, вот и вся логика.
Но мониторинг предложений о работе явно говорит о том, что найти работу кодеру на яве сложнее, чем любому пишущему на указанной троице, вот и вся логика.
Но какой в этом смысл, если таких вакансий в пять-десять раз меньше?
Ну не лукавьте, я рассматриваю в основном PHP, JS и Node.
В целом, я понимал, что конкретно этот вопрос в статье спорный изначально. Но во первых — я сам не большой знаток Java и .Net стека, а писать о том чего не знаешь дело неблагодарное. И времени для изучения конкретно сейчас нет.
Во вторых, мне хотелось как-то всё-таки сузить круг для человека, который выбирает путь дальнейшего развития. Чтобы это сделать — идеальный вариант это описать плюсы и минусы технологии, что без её знания затруднительно. Поэтому критерием и стали предложения о работе, что нельзя считать таким уж малозначимым фактором.
Разумеется, я мог где-то нерелевантную выборку составить по этим профессиям, но ведь и цель статьи — не показать рынок труда, а рассказать про основные.
Словом, тут я мог ошибиться, конечно же.
В целом, я понимал, что конкретно этот вопрос в статье спорный изначально. Но во первых — я сам не большой знаток Java и .Net стека, а писать о том чего не знаешь дело неблагодарное. И времени для изучения конкретно сейчас нет.
Во вторых, мне хотелось как-то всё-таки сузить круг для человека, который выбирает путь дальнейшего развития. Чтобы это сделать — идеальный вариант это описать плюсы и минусы технологии, что без её знания затруднительно. Поэтому критерием и стали предложения о работе, что нельзя считать таким уж малозначимым фактором.
Разумеется, я мог где-то нерелевантную выборку составить по этим профессиям, но ведь и цель статьи — не показать рынок труда, а рассказать про основные.
Словом, тут я мог ошибиться, конечно же.
Вы извините, я считаю что до этого уровня в любой сфере дорастают всё-таки немногие кодеры, странно считать это ориентиром.
Кодеры — наверное нет, разработчики вполне. Причем независимо от платформы. Под разработчиком понимаю человека, который нацелен не написание кода и придачи ценности коду как таковому, а на создание продукта со всеми вытекающими(проектирование фич, выяснение ограничений и подходящего инструментария и т.п)
Буквоедство, не?
Да причем тут буквоедство — нередко народ пишет код не понимая в конечном счете с чего именно идет инкам для компании и что код это всего лишь строчки текста, по сути ничего не стоящие. Но с позиции своего максимализма или отсутствия опыта или еще чего придают именно этим строчкам кода именно на его/ее любимой платформе очень много значения, даже не пытаясь мыслить продуктово. Обычно такие же люди готовы рефакторить все и вся, не приемлят каких то отступлений в сторону говнокода в угоду time-to-market и вот это все.
Кодер — просто человек, умеющий писать код, реализовывать алгоритм здесь и сейчас.
Кодер — просто человек, умеющий писать код, реализовывать алгоритм здесь и сейчас.
Кодер — просто человек, умеющий писать код, реализовывать алгоритм здесь и сейчасКодер — просто более удобное слово, вместо длинных и неудобных «программист» или «разработчик». Никаких других смыслов тут нет. То что вашему самолюбию оно претит — вопрос лично ваших взглядов, не более.
Самолюбие не при чем. Если для вас разработчик — любой человек пишущий код — пусть будет так. В моем понимания разработка больше про создание продукта со всеми вытекающими кроме написания кода. Поэтому останемся каждый при своем мнении.
Как можно писать код и не быть при этом разработчиком?
Человек, который просто переводит написанный другим сотрудником алгоритм на язык программирования, формально пишет код, но при этом может совершенно не понимать бизнес-требований. Будет ли он при этом являться разработчиком?
Ну, с моей точки зрения, да, хотя и не полноценным. И вот почему — сможет ли он корректно перевести алгоритм с одного языка на другой, совсем ничего не зная про бизнес-модель и окружение?
Если речь про одну-две функции, понятно что это возможно. Только подобным даже не «кодер» занимается, а стажёр-студент какой-нить. К слову, студенты, когда язык учат, по факту ещё ни кодерами, ни разработчиками не являются. Если строго следовать данной терминологии, их только и остаётся что студентами называть.
Ну и в любом случае, это пустые придирки к словам идут, по моему мнению. Ситуации, когда человек просто пишет код, абстрактно, без привязки к какому-либо продукту или конкретной цели, как какая-нибудь Ада Лавлейс, бывают разве что в вакууме.
А навешивая ярлыки «кодер», «программист», «разработчик», и прочее, мы в какую-то палочно-армейскую систему себя загоняем, к чему это?
Если речь про одну-две функции, понятно что это возможно. Только подобным даже не «кодер» занимается, а стажёр-студент какой-нить. К слову, студенты, когда язык учат, по факту ещё ни кодерами, ни разработчиками не являются. Если строго следовать данной терминологии, их только и остаётся что студентами называть.
Ну и в любом случае, это пустые придирки к словам идут, по моему мнению. Ситуации, когда человек просто пишет код, абстрактно, без привязки к какому-либо продукту или конкретной цели, как какая-нибудь Ада Лавлейс, бывают разве что в вакууме.
А навешивая ярлыки «кодер», «программист», «разработчик», и прочее, мы в какую-то палочно-армейскую систему себя загоняем, к чему это?
Человек, который просто переводит написанный другим сотрудником алгоритм на язык программирования, формально пишет код, но при этом может совершенно не понимать бизнес-требований. Будет ли он при этом являться разработчиком?
Конечно.
Для этого существуют тим лиды и бизнес аналитики. Для этого существуют менеджеры.
В крупных проектах, когда продукт пилит десятки сотни и тысячи людей, подавляющее большинство разработчиков бизнес-требований могут и не понимать, пиля свою маленькую таску.
Собственно можно не изобретать свое значение терминов, а посмотреть оригинальные, англоязычные, где кодер от разработчика отличается именно тем, что кодер больше относится к программированию на языке программирования, а разработчик — о продукте вообще.
Считать, что разработчик это следующая эволюция кодера — некорректно. Квалификация пересекается частично.
Да речь не о таком уровне(и лид больше про управление командой) И контор, где пилят десятки тысяч людей не так много, по крайней мере в РФ — куда больше реальности, что человек будет работать в обычно средней конторе со своим набором продуктов-услуг.
Суть не в терминах, а в том есть или нет у кодера/разработчика понимание бизнес-ценностей, так называемого value, что зп ему прилетает от продукта для которого он пишет фичи и не за те строчки кода, который сами по себе ценности не имеют(привет любителям рефакторинга ради рефакторинга) И обычно такое понимание приходит после уровня миддла, а бывает и не приходит и человек вроде и имеет опыт 5-6 лет, а все так же др… ит на вылизанный код и без привязки к продукту и необходимости такой вылизанности. Утрирую, но думаю суть понятна.
Суть не в терминах, а в том есть или нет у кодера/разработчика понимание бизнес-ценностей, так называемого value, что зп ему прилетает от продукта для которого он пишет фичи и не за те строчки кода, который сами по себе ценности не имеют(привет любителям рефакторинга ради рефакторинга) И обычно такое понимание приходит после уровня миддла, а бывает и не приходит и человек вроде и имеет опыт 5-6 лет, а все так же др… ит на вылизанный код и без привязки к продукту и необходимости такой вылизанности. Утрирую, но думаю суть понятна.
Это зависит от менеджера проекта.
Если он хочет вовлести разработчиков в бизнес-процессы, он это делает.
Проводит регулярные таунхолы, где популярно на хай-левеле поясняет что и куда идет проект, кому он нужен, как он используется.
Это позволяет повысить вовлеченность людей.
В случае продуктовых компаний, даже джуниоры могут выдвинуть полезные идеи.
И да, разработчик может знать о бизнес-процессе, может не знать. Он от этого разработчиком быть не перестанет.
Если он хочет вовлести разработчиков в бизнес-процессы, он это делает.
Проводит регулярные таунхолы, где популярно на хай-левеле поясняет что и куда идет проект, кому он нужен, как он используется.
Это позволяет повысить вовлеченность людей.
В случае продуктовых компаний, даже джуниоры могут выдвинуть полезные идеи.
И да, разработчик может знать о бизнес-процессе, может не знать. Он от этого разработчиком быть не перестанет.
Для этого существуют тим лиды и бизнес аналитики. Для этого существуют менеджеры.
Угу, а потом случается бессмертное "Кто сшил костюм?" вместе с "К пуговицам претензии есть?"...
В моем предыдущем сообщении «кроме» имелось ввиду как «помимо».
Собственно, выше отлично выразили и дополнили мою мысль.
Собственно, выше отлично выразили и дополнили мою мысль.
если вы не собираетесь этот код поддерживать то вы просто кодер
Но ведь вы его разработали.
здесь ключевой момент именно в поддержке. мне много приходилось работать с чужим кодом, и я могу сказать что 50% развалившихся проектов развалились потому, что при проектировании системы не было учтена поддержка. тоесть люди писали код зная, что поддерживать его будут не они. в итоге в их коде никто не мог разобраться, или на нём не было возможности построить новые части системы, или он был сделан на неудобных фреймворках, или были использованы не те инструменты…
вот и получается разница между программистом и кодером очень большая — для начала, тестирование. кто из начинающих разработчиков в своём первом проекте использует тесты? кто правильно делит код на классы? использует паттерны/фреймворки? как правильно делать композицию? как построены абстракции?
когда код решает поставленную задачу это значит код ничего не решает, и цена ему — зарплата, которую выдали программисту. код начинает иметь экономический смысл, когда стоимость его поддержки снижается по сравнению с прибылью, которую он приносит. тоесть отличие кодера от инженера — в экономической плоскости а не в технической.
видите ли вы стратегию бизнеса в котором работаете? учитываете ли возможные изменения в архитектуре, закладываете ли вы основу для них в самом начале, чтобы когда они понадобятся вам не приходилось менять место работы/телефон/адрес?
как скзал какой-то известный чувак, «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте»
вот в этом отличие мне кажется
когда я был начинающим кодером на PHP у меня была одна большая функция, которая генерировала сайт заново каждый раз при его изменении… тем не менее, клиент много на нём заработал, сайт висел год в топе яндекса именно потому что там было всё новое и сайт был статичным… мне до сих пор стыдно за этот код, хотя он работал.
сейчас, после 15 лет практики и завершённых крупных проектах, которые работают по нескольку лет — я могу сказать в чём разница. именно в эгоизме. мне жалко себя, жалко своё время, которое я потрачу на отладку плохо написанного кода без тестов. поэтому я мыслю так что поддерживать код буду я от начала и до конца проекта. это одна из причин по которой я работаю на стеке .Net/C#. этот стек провоцирует писать правильную архитектуру, провоцирует рециркулировать код, разделять проекты, переиспользовать проекты в других решениях, организовывать всё в git, писать в TDD стиле — потому что тестирование очень удобно встроено в VisualStudio. с выходом .net standard 2.1 появилась возможность рециркулировать код на сервере/десктопе/мобильных устройствах, а это огромный прорыв для сложных систем. у меня на рабочем проекте (ERP) работает сложный код вычисления рецептов для мороженого, работа с оборудованием — и я бы задолбался портировать это всё с серверного кода на десктоп. а на .net у меня отлично получилось. так что получается вы самый класный фреймворк и не рассмотрели. EF потрясающая тема опять же… советую обратить внимание на asp.net, после него вам не захочется писать ни на чём другом (если проект достаточно сложный и гибкий)
вот и получается разница между программистом и кодером очень большая — для начала, тестирование. кто из начинающих разработчиков в своём первом проекте использует тесты? кто правильно делит код на классы? использует паттерны/фреймворки? как правильно делать композицию? как построены абстракции?
когда код решает поставленную задачу это значит код ничего не решает, и цена ему — зарплата, которую выдали программисту. код начинает иметь экономический смысл, когда стоимость его поддержки снижается по сравнению с прибылью, которую он приносит. тоесть отличие кодера от инженера — в экономической плоскости а не в технической.
видите ли вы стратегию бизнеса в котором работаете? учитываете ли возможные изменения в архитектуре, закладываете ли вы основу для них в самом начале, чтобы когда они понадобятся вам не приходилось менять место работы/телефон/адрес?
как скзал какой-то известный чувак, «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте»
вот в этом отличие мне кажется
когда я был начинающим кодером на PHP у меня была одна большая функция, которая генерировала сайт заново каждый раз при его изменении… тем не менее, клиент много на нём заработал, сайт висел год в топе яндекса именно потому что там было всё новое и сайт был статичным… мне до сих пор стыдно за этот код, хотя он работал.
сейчас, после 15 лет практики и завершённых крупных проектах, которые работают по нескольку лет — я могу сказать в чём разница. именно в эгоизме. мне жалко себя, жалко своё время, которое я потрачу на отладку плохо написанного кода без тестов. поэтому я мыслю так что поддерживать код буду я от начала и до конца проекта. это одна из причин по которой я работаю на стеке .Net/C#. этот стек провоцирует писать правильную архитектуру, провоцирует рециркулировать код, разделять проекты, переиспользовать проекты в других решениях, организовывать всё в git, писать в TDD стиле — потому что тестирование очень удобно встроено в VisualStudio. с выходом .net standard 2.1 появилась возможность рециркулировать код на сервере/десктопе/мобильных устройствах, а это огромный прорыв для сложных систем. у меня на рабочем проекте (ERP) работает сложный код вычисления рецептов для мороженого, работа с оборудованием — и я бы задолбался портировать это всё с серверного кода на десктоп. а на .net у меня отлично получилось. так что получается вы самый класный фреймворк и не рассмотрели. EF потрясающая тема опять же… советую обратить внимание на asp.net, после него вам не захочется писать ни на чём другом (если проект достаточно сложный и гибкий)
У вас какая-то травма психологическая просто, ущемление собственной важности, или я хз…
Эти слова — синонимы. А тот смысл который вы в каждое из них вкладываете это ваши личные филосовско-субъективные переживания и осмысления и не более.
Эти слова — синонимы. А тот смысл который вы в каждое из них вкладываете это ваши личные филосовско-субъективные переживания и осмысления и не более.
когда я был начинающим кодером на PHP у меня была одна большая функция, которая генерировала сайт заново каждый раз при его изменении… тем не менее, клиент много на нём заработал, сайт висел год в топе яндекса именно потому что там было всё новое и сайт был статичным… мне до сих пор стыдно за этот код, хотя он работал.
Другими словами, вы написали говнокод, за который вам стыдно, но клиент при этом много заработал доволен, а значит, согласно ВАШИМ ЖЕ СЛОВАМ, а именно:
код начинает иметь экономический смысл, когда стоимость его поддержки снижается по сравнению с прибылью, которую он приносит.
говнокодить — норм, пока это экономически выгодно.
Так вот. Не знаю какой там у вас опыт, 15 лет вроде. Должны был уже повидать мир и разные проекты и понять, что говнокодить — экономически выгодно почти всегда.
как раз наоборот, я даже в своих домашних проектах сейчас использую TDD и делаю всё максимально красиво, как раз потому что это экономически выгодно. я экономлю время, как своё так и заказчика, особенно на поздних этапах работы проекта, мой код имеет ценность в долгосрочной перспективе, и то что люди вынуждены писать говнокод это мне кажется скорее от недостатка опыта чем осознанный выбор стратегии
но ведь на пять-десять стульев сразу и не сядешь…
Ну например, если брать Минск, то Java/Scala/Kotlin Senior от $3k до $5k, а С/С++ Senior от $4.5k (Это даже если не брать игрушки) хотя вакансий очень мало. Но могу сказать что и программистов мало, на вес золота почти.
Легко ли найти работу на Java? Супер легко! Если есть хоть какие то вменяемые знания. Работы по Java очень много и людей HRы рвут на части. Но Java, в основном, это крупный Enterprise, ниша быдлокодеров тут индусами занята, в Россию, да и вообще СНГ, заказчики идут за качеством по ± приемлемой цене, так что уровень знаний требуется на порядок выше чем для языков с «низким порогом вхождения».
Где-то рядом со всей этой тусовкой топчется Microsoft со своим SharePoint
Вероятно, вы не совсем в ту сторону смотрели. Sharepoint — это очень специфичная вещь. У Microsoft есть ASP.Net (в разных ваканиях упоминают разные вариации web, mvc, webapi, core) — думаю более используемая штука, чем тот же Ruby on Rails.
Пожалуй вы правы. Sharepoint, это наверное что-то больше из разряда CMS…
Вечерком поправлю это дело, спасибо.
Вечерком поправлю это дело, спасибо.
Если точнее, то «шарик» занимает нишу Enterprise Content Management и Business Process Management.
«Классическую» CMS из него тоже пытались сделать, но вышло ИМХО так себе: врождённая корявость HTML редактора и излишне замороченный подход к модификации внешнего вида сайта делают «шарик» совершенно неконкурентоспособным в этой нише.
«Классическую» CMS из него тоже пытались сделать, но вышло ИМХО так себе: врождённая корявость HTML редактора и излишне замороченный подход к модификации внешнего вида сайта делают «шарик» совершенно неконкурентоспособным в этой нише.
Активно набирает обороты опенсоурсный .net core, многие в корпоративном секторе уже поглядывают на него, размышляя. а не перейти ли на него с Java
Я надеюсь, что когда вас возьмут на работу, то будут платить $10 000 в месяц. Без этого знать столько всего сразу несколько бессмысленно.
Поясню коммент выше:
Если под фулстеком подразумевается node.js на фронте и беке, то ок. Если node.js на фронте и приемлемый код на PHP на беке, то даже тут ок. Но если подразумеваевается node.js на фронте и хороший код на беке с хорошими архитектурными заделами, то я таких фронтендеров не встречал.
Все фулстек, которых я встречал, хорошо пишут фронтеэнд сторону и копипастят подходы в готовом продукте на беке. Потом это надо ревьювить и делать красивым.
Если под фулстеком подразумевается node.js на фронте и беке, то ок. Если node.js на фронте и приемлемый код на PHP на беке, то даже тут ок. Но если подразумеваевается node.js на фронте и хороший код на беке с хорошими архитектурными заделами, то я таких фронтендеров не встречал.
Все фулстек, которых я встречал, хорошо пишут фронтеэнд сторону и копипастят подходы в готовом продукте на беке. Потом это надо ревьювить и делать красивым.
Ну не знаю… Я вообще программировать учился на крестах изначально. Поэтому до сих пор не встречал ни одной сложной для понимания концепции в PHP. Писать самому поначалу непривычно, но с чужим кодом чаще вопросов куда больше возникает, поэтому в итоге всё равно приходишь к тому, что сам пишешь.
Думаю проблема основная в том, что многие люди идут в web, не имея изначально глубокого знания какого-либо серьёзного языка. Я, собственно, именно про ООП и упомянул в первом списке.
Думаю проблема основная в том, что многие люди идут в web, не имея изначально глубокого знания какого-либо серьёзного языка. Я, собственно, именно про ООП и упомянул в первом списке.
node.js на фронте
Это словосочетание конкретно рвёт мне шаблон. Node.js работает на сервере. Сервер — это бэкенд. Фронт — это в браузере. Или я где-то глубоко заблуждаюсь?
Однако это так и есть. Имеется ввиду что node.js используется просто как средство автоматизации самых различных задач во фронте. Большинство современных фронтовых тулов, которых тысячи, сделаны на ноде, но работают они как правило локально, без поднятия сервера, то есть это просто скрипты процессы которых чаще всего убиваются после завершения задачи.
Ну C#/.Net — может ещё может потягаться с тем же руби. Но ява проигрывает явно по всем фронтам. Даже если вакансий больше в целом, значимая часть из них — это не именно бэкэнд, а например что-то специализированное внутри компании. Какие-нить клиенты для внутренних ERP-систем, например, частенько на C#/.Net и пишутся. Как долю оценивать я не знаю. В любом случае она меньше чем у популярных направлений. Ну а объять всё за раз невозможно, поэтому решил про это не писать вовсе.
«Symfony OR Laravel OR Yii» — 434 вакансии.
У нас с вами какой-то разный ХХ
«Java Spring» — 535 вакансий. Из них минимум процентов 15 — никак не связанные именно с веб-бэкэнд.
Несколько примеров, которые по этому запросу находятся:
hh.ru/vacancy/29898913?query=Java%20Spring
hh.ru/vacancy/30416742?query=Java%20Spring
Очень показательный пример:
hh.ru/vacancy/30180699?query=Java%20Spring
Я просто знаком с продуктами этой компании. Это не Backend для web'а. Да, там используются практически те же технологии, например REST, но это всё же иная сфера.
И таких вакансий, на самом деле, явно больше 15%, я же не буду их все просматривать, ну. Это нерелевантная выборка.
У PHP и Node вакансий будет больше в итоге.
Какая разница для чего бэкенд: для веба, для мобильников или десктопного приложения?Разница в том, что статья про web-разработку была, так-то…
Вообще ради чего вы так упрямо пытаетесь принизить Java по количествуНе пытаюсь, что вы. Я лишь пытаюсь объяснить почему предпочтение для обзора отдано не этому языку, возможно я не до конца верно мысль излагаю.
и качеству вакансий?Тут тем более нет, я вообще это даже не обсуждал, ибо сам считаю эту технологию, в целом, лучше чем многие другие интерпретируемые языки, несмотря даже на её давние проблемы, в виде дыр в безопасности её рантайма, например.
Ну, у меня такое ощущение, что вы оставили только те языки, про которые что-то знаете. Это как если бы я писал: PHP устарел, не учите его(это кстати разве не так?), учите Java, на ней держится мир бэкенда. Ну и Node.js можете учить. Про RoR ничего не напишу вообще, потому что я про него не знал(аналогия с C#).
Напомню, что изначальная ваша позиция была такая: «Даже если вакансий больше в целом, значимая часть из них — это не именно бэкэнд, а например что-то специализированное внутри компании». То есть вы прямо сказали, что на Java вакансий по бэкенду мало.
Ну так мы и пришли к тому, что вакансий на web-бэкэнд на Java меньше, чем на остальные языки.
Ошибся я, по сути, только в том, что шарп не стал учитывать.
Да не меньше! Java уверенно занимает большой кусок backend`a.
Странные у нас у всех поиски, приведу свой(с hh, по России) по запросу
Java — 1032
PHP — 908
Python — 748
Node.js — 435
А если просто по запросу
Java — 6000
PHP — 4200
Python — 5100
JavaScript — 8000, из них Node.js — 1159
Странные у нас у всех поиски, приведу свой(с hh, по России) по запросу
яп backend:Java — 1032
PHP — 908
Python — 748
Node.js — 435
А если просто по запросу
яп, то вот:Java — 6000
PHP — 4200
Python — 5100
JavaScript — 8000, из них Node.js — 1159
Ну C#/.Net — может ещё может потягаться с тем же руби. Но ява проигрывает явно по всем фронтам
Даже если вакансий больше в целом, значимая часть из них
В каком регионе, если не секрет? На headhunter по кейворду Java есть 1100 вакансий в Питере, 500 по C# и чуть больше 100 для Ruby.
По России искал.
То же самое — 6K на яве, 3.8К на шарпе, 700 на руби.
А как вы вакансии шарпа, разделили на те, что для web и остальные?
Там сложно так сходу сказать, но запрос "c#" and (asp.net or javascript or typescript or web or веб or fullstack) выдаёт 2.3К вакансий(т.е. с явным требованием чего-то вебового) — больше половины от всех.
Аналогичный запрос для java — 3.2K.
Для руби, кстати, тоже не везде веб в вакансиях — разрыв сохраняется.
Если хотите оценить именно позиции для веб-бэкенда, ищите по названию основного фреймворка, т.е. «ASP.net» или «Spring», как уже посоветовали выше.Согласен, это было бы релевантнее. Но сопоставление и получение результатов было бы слишком затратным для использования в качестве примера. Это же всё-таки не исследование рынка, тут цель была другая.
А что до широты применения — так это наоборот плюс, т.к. даёт возможность потом при желании легко перейти из веба в мобильную или десктопную разработку, к примеру.Опять же, нисколько не критикую широту применения, я сам за изучение базовых ООП-языков типа Си в начале практики любого программирования. Просто речь именно про web.
Ну возможно. Дело в том, что ощущение того, что я понимаю чего ж там именно всё-таки происходит с кодом в интерпретаторе\компиляторе, когда я составляю те или иные языковые конструкции, пришло только после изучения нескольких ООП-языков.
Конечно, в моём случае, основной толчок к пониманию базовых концепций дал именно С++. Но, тем не менее, более чётко всё осознать удалось уже после него, уже чуть позже, когда возился с PHP и (параллельно с асмом для МК). Потому я считаю, что порядок не важен и любой язык может дать представление.
Опять же, до плотного изучения крестов в вузе нам преподавали Delphi\Pascal, думаю это тоже роль в понимании сыграло.
Конечно, в моём случае, основной толчок к пониманию базовых концепций дал именно С++. Но, тем не менее, более чётко всё осознать удалось уже после него, уже чуть позже, когда возился с PHP и (параллельно с асмом для МК). Потому я считаю, что порядок не важен и любой язык может дать представление.
Опять же, до плотного изучения крестов в вузе нам преподавали Delphi\Pascal, думаю это тоже роль в понимании сыграло.
Помните о stackshare.io чтобы быть в курсе, что используется в топовых и не очень компаниях
Спасибо, видел сервис раньше, но не смог нагуглить.
Еще есть www.libhunt.com
Аналогично было, ушел (С++ бэкэнд винда, com-объекты) что называется в блудняк на ~10 лет (иногда баловался php, html/css). Возвращаться ой как тяжело, пробовал волнами (руки опускались от растерянности), непонятно куда ткнуться, полно технологий живущих на хайпе 1-2 года. Ошибался, веря IT-псевдоаналитикам, гадалкам и астрологам, переполняла смесь восхищения от стремительного развития отрасли и недоумение от нехватки профессионалов. Сначала с фронтэндом разобрался, для бэкэнда сейчас поглощаю asp.net core (c# понятен и понравился f#), архитектуры приложений, книжки по алгоритмам, нейросетям, в AI погружаюсь, купил для исследований RealSense-камеру, нейрогарнитуру. Мне 40+, боязно работу искать, что там в резюме показывать. Свой проект пилить буду. Благо идеи есть. Дорогу осилит идущий…
для бэкэнда сейчас поглощаю asp.net core (c# понятен и понравился f#)
Возможно я отстал от реалий рынка и меня поправят, но кажется вы опять промазали со стеком.
.NET сейчас на взлёте, в отличие от Java (спасибо Kotlin), так что выбор как раз оправдан
mkshma Это вы об этом?
Да, была такая дилемма ) Но уже есть .Net Core, перспективы его интересны. Почитайте статью на хабре Через год-два .NET Core потеснит Java на рынке enterprise решений...
Тут пришлось выбирать. Я не был привязан ни к одной платформе. Но мне показалось сейчас разумным, перспективным и универсальным (бэкэнд, мобильная разработка, фронтэнд пишем уже скоро в wasm) выбрать именно платформу. Кстати на C# ставку не делаю, изучаю F# (в AI, финансах активнее стали использовать).
p.s. Пробовал Kotlin — понравился, приятный язык.
.Net vs Java
Да, была такая дилемма ) Но уже есть .Net Core, перспективы его интересны. Почитайте статью на хабре Через год-два .NET Core потеснит Java на рынке enterprise решений...
Тут пришлось выбирать. Я не был привязан ни к одной платформе. Но мне показалось сейчас разумным, перспективным и универсальным (бэкэнд, мобильная разработка, фронтэнд пишем уже скоро в wasm) выбрать именно платформу. Кстати на C# ставку не делаю, изучаю F# (в AI, финансах активнее стали использовать).
p.s. Пробовал Kotlin — понравился, приятный язык.
Мне программировать на C# понравилось гораздо больше, чем на Java.
Основная причина: языковые возможности. Java по сравнению с C# слишком консервативна. Многие возможности в ней появились через пару-тройку лет после C#. А некоторые так и не появились: value types, поддержка дженериков со стороны JVM и т.д.
Основная причина: языковые возможности. Java по сравнению с C# слишком консервативна. Многие возможности в ней появились через пару-тройку лет после C#. А некоторые так и не появились: value types, поддержка дженериков со стороны JVM и т.д.
С первого взгляда есть несколько замечаний по фронтенду. Во-первых, с приходом ES6 язык сильно изменился в лучшую сторону. По крайней мере странно отказываться от применения новых возможностей и называть «чистым JS» устаревший стандарт. Будущее веб-компонентов наступает, наступает, а наступить никак не может. Стоит ли их использовать — большой вопрос. Зато переменные в CSS уже есть. Компиляция LESS на клиенте — это весьма проблемный подход, а в вашем примере вы рассчитываете значение 100vh. Зачем? XPath может быть полезен при тестировании сценариев взаимодействия, в остальном его обычно некуда применить. Собирать и тестировать все каждый раз перед отдачей клиенту? А как же производительность? Обычно это делают заранее и на продакшен-сервер заливают готовые скрипты и CSS. Стоит упомянуть PostCSS как хорошее подспорье при верстке (автопрефиксер, проверка совместимости с браузерами и.т.д.). То, что Webpack может заменить Bower — это глупость. Инструменты решают принципиально разные задачи. Gulp и Webpack могут работать вместе и успешно дополнять друг друга.
Во-первых, с приходом ES6 язык сильно изменился в лучшую сторону.Ну я не говорил, что он стал хуже.
По крайней мере странно отказываться от применения новых возможностей и называть «чистым JS» устаревший стандарт.Ну, скажем, я всё же обычно под «чистым JS» подразумеваю ES в сравнении с TypeScrpit или CoffeeScript.
Компиляция LESS на клиенте — это весьма проблемный подход, а в вашем примере вы рассчитываете значение 100vh. Зачем?Очевидно, это всё только для примера. Я предпочитаю ни SASS, ни LESS вообще не использовать без крайней необходимости. Что касается переменных в CSS, то они до сих пор процентов у 40 пользователей в браузере не работают.
PostCSSне слышал. Почитаю, спасибо.
То, что Webpack может заменить Bower — это глупость.Не согласен. Очевидно что задачи изначально у них разные, но имеется ввиду, что для загрузки можно использовать NPM, который есть по умолчанию, а соберёт всё Webpack. Собственно, погуглите, так частенько делают.
При том, что его можно заменить, используя импорты с помощью в Webpack, что тут непонятного?
Можете спросить у разработчиков Bower, которые сами предлагают его менять на Webpack на первой же странице:
bower.io
Если вас интересует лично моё мнение — у всей этой мешанины с нодой, трасплейтерами и бандлерами, вообще перед обычной примитивной IDE (типа Atom'а) и написанием классического кода на JS вообще без всяких модулей — преимуществ в абсолютном большинстве случаев нет никаких. Преимущества появляются, когда проект дорастает до определённого размера.
bower.io
Если вас интересует лично моё мнение — у всей этой мешанины с нодой, трасплейтерами и бандлерами, вообще перед обычной примитивной IDE (типа Atom'а) и написанием классического кода на JS вообще без всяких модулей — преимуществ в абсолютном большинстве случаев нет никаких. Преимущества появляются, когда проект дорастает до определённого размера.
что касается переменных в CSS, то они до сих пор процентов у 40 пользователей в браузере не работают.
Ну не знаю, очень странная статистика. Например, что у них единственная отмеченная версия Chrome for Android это 71, а Firefox for Android это 64. Как это понимать? С остальными чё?
Кроме того, у меня, на личном проекте с 1000+ посетителей в день, я вижу что до сих в статистике, например, одной оперы ниже указанной 35-й версии, всё ещё есть целых 1.5%. А у IE 5.5%, который даже не Edge. Это уже 7%, а я ещё не учёл старые мобильные версии, всякие Яндекс-браузеры и прочий хлам, которого вообще-то у посетителей очень много, а по ссылке выше нет вообще.
Пусть не 40, конечно, тут я погорячился, но 25% наверняка наберётся, что, опять же, всё ещё рановато.
Кроме того, у меня, на личном проекте с 1000+ посетителей в день, я вижу что до сих в статистике, например, одной оперы ниже указанной 35-й версии, всё ещё есть целых 1.5%. А у IE 5.5%, который даже не Edge. Это уже 7%, а я ещё не учёл старые мобильные версии, всякие Яндекс-браузеры и прочий хлам, которого вообще-то у посетителей очень много, а по ссылке выше нет вообще.
Пусть не 40, конечно, тут я погорячился, но 25% наверняка наберётся, что, опять же, всё ещё рановато.
300+ тысяч. уникальных посетителей в год. Для стран СНГ, как мне кажется, плюс-минус ничего такая статистика.
Не миллионы конечно, но это и не обычный хомяк уже.
Не миллионы конечно, но это и не обычный хомяк уже.
Метрика не позволяет выбрать больше 30 или 40 версий за раз, а их гораздо больше. Я даже все версии хрома, которые переменные не поддерживают, не смог на одном графике выбрать, не то что остальные. Можно было бы отдельно посчитать, но мне тупо лень — вы абсолютно бестолковый холиварщик, который ничего не в состоянии сказать по сути, зато в собственных комментах путается, диалог с вами абсолютно бессмысленен, извините.
единственная отмеченная версия Chrome for Android это 71, а Firefox for Android это 64. Как это понимать? С остальными чё?
Остальные не используются. На вкладке "Usage relative" лучше видно.
В итоге, работает у 87.39% клиентов, не работает у 12.61%. Это всё же не 40% и не 25%, хотя и не 0%.
Остальные не используются.Да? А куда они деваются? Я вот не обновлял полгода ничего из маркета на старом смартфоне, но использую его для тестов интерфейса на работе.
Один смарт отдал бабушке, думаете она там браузер обновляла? А она им пользуется, я вам гарантирую. Таких кейсов с десятки наберётся.
https://caniuse.com/usage-table
У них действительно нет версий мобильного Chrome и Firefox, кроме последних. Но на этой же станице они пишут:
Browser usage table, based on data from StatCounter GlobalStats
Information for mobile versions is extrapolated from other sources.
Либо эти браузеры обновляются своевременно и доля устаревших версий пренебрежительно мала, либо caniuse плохо экстраполирует :)
В пользу первого варианта говорит то, что другие мобильные браузеры всё же разбиты на версии.
У них действительно нет версий мобильного Chrome и Firefox, кроме последних.Ну так это говорит лишь в пользу того, что их статистика — рафинированный булшит.
Либо эти браузеры обновляются своевременно и доля устаревших версий пренебрежительно малаОй лан, прекратите…
И это даже не половина списка, мне просто лень скринить остальное
Это всё только за полгода. Для мобильной лисы ситуация аналогичная.
На самом деле у них и половины того, что есть у пользователей, нету в списке.
Ну, скажем, я всё же обычно под «чистым JS» подразумеваю ES в сравнении с TypeScrpit или CoffeeScript.
Процитирую вас же.
От себя скажу, что некоторые дополнительные фишки действительно очень удобны (например классы в ECMAScript 6, позволят писать заметно меньше кода, но мозг ломают знатно). Впрочем лично я являюсь приверженцем использования чистого JS, без всяких надмножеств, и без крайней необходимости новые возможности стараюсь не использовать.
Здесь как-то контекст теряется.
имеется ввиду, что для загрузки можно использовать NPM, который есть по умолчанию, а соберёт всё Webpack
Вижу теперь вы добавили в статье NPM, а то раньше звучало так, что вы заменяете Bower+Gulp на Webpack.
Bower уже почти 2 года рекомендует перестать им пользоваться и переходить на Yarn/NPM.
bower.io/blog/2017/how-to-migrate-away-from-bower
bower.io/blog/2017/how-to-migrate-away-from-bower
Видать вы не сильно то и деградировали эти десять лет, просто тогда ещё perl в моде был
Не просто по IDE, а как её использовать по максимуму, включая знание всех горячих клавиш, полезные плагины и написание макросов
С учётом особенностей нетипизированных языков, я бы ещё сказал. Автор, к примеру, отмахивается от TypeScript, который лично мне очень сильно облегчает жизнь в основном именно за счёт поддержки в IDE — при попытках писать на чистом JS даже WebStorm (уж на что он в этом плане умный) гораздо реже может подкинуть что-то вменяемое в автодополнении, а об авторефакторинге часто лучше даже не думать.
Автор из эпохи vim-а и emacs-а судя по всему. Хотя даже там были всякие плагины для какого-никакого автодополнения, если не ошибаюсь…
Ну, кстати, vim мне лично никогда не нравился.
Сейчас пользуюсь Atom'ом и, иногда VSCode, для проектов на Node. Но предпочтение всё же отдаю Atom'у (и иногда Notepad2). До сих пор считаю, что чем проще инструмент, тем лучше.
Сейчас пользуюсь Atom'ом и, иногда VSCode, для проектов на Node. Но предпочтение всё же отдаю Atom'у (и иногда Notepad2). До сих пор считаю, что чем проще инструмент, тем лучше.
В случае языков с динамической типизацией действительно можно обойтись редактором с подсветкой синтаксиса. Но если вы начнёте использовать языки со статической типизацией, вы поймёте, насколько же приятно использовать IDE в работе.
А как типизация на это влияет? Для C++ я писал в Builder и потом уже под RAD, оно, конечно удобнее, но по другим причинам — в первую очередь потому, что в С++ есть компиляция, а в этих IDE отладчик встроенный. Хотя пара фич у умных IDE действительно есть, которых лично мне, по большому счёту, не хватает в простых редакторах:
— Удобный всех мест в проекте где вызывается функция (как в Storm от JetBrains, хотя может у других есть такое же). Хотя в том же Atom это можно заменить «поиском по проекту».
— Вывод списка аргументов, которые принимает функция и их типов, по мере ввода.
— Статический анализ.
Но эти вещи никак с типизацией не связаны, вроде бы.
— Удобный всех мест в проекте где вызывается функция (как в Storm от JetBrains, хотя может у других есть такое же). Хотя в том же Atom это можно заменить «поиском по проекту».
— Вывод списка аргументов, которые принимает функция и их типов, по мере ввода.
— Статический анализ.
Но эти вещи никак с типизацией не связаны, вроде бы.
А как типизация на это влияет?
Статическая типизация позволяет более интеллектуально делать поиск по проекту, осуществлять рефакторинги.
Для C++ я писал в Builder и потом уже под RAD
В них очень слабый анализ кода. Не сильно лучше редактора с подстветкой синтаксиса. Зато есть отладчик — это большой плюс.
— Удобный всех мест в проекте где вызывается функция (как в Storm от JetBrains, хотя может у других есть такое же). Хотя в том же Atom это можно заменить «поиском по проекту».
Поиск по проекту выдаст много нерелевантных результатов. Например, у вас объявлен метод с одинаковым именем в нескольких классах. В случае динамической типизации вы в общем случае не знаете, с объектом какого типа работаете, поэтому придётся выдавать все возможные варианты.
— Вывод списка аргументов, которые принимает функция и их типов, по мере ввода.
Отлично. И как же вывести параметры метода при условии, что тип объекта неизвестен? Или предлагаете пользоваться только статическими функциями?
Отлично. И как же вывести параметры метода при условии, что тип объекта неизвестен?Я имел ввиду в основном именно аргументы к функции, которые, очевидно IDE ищет всё-таки по имени функции, а не по типу. В случае объектов с не объявленным типом, список методов, очевидно, никак не вывести. Однако есть разные ситуации, например, если я нахожусь внутри функции, при объявлении которой указал, что принимаю в качестве аргумента массив, то можно показывать методы, доступные для массива, например, какие проблемы?
Объектно-ориентированный подход в программировании.
Системы контроля версий.
Концепция MVC
Методологии разработки Agile и Scrum
Это шутка? Этим вещам по 10-20 лет, если не больше.
Yii — считается одним из наиболее производительных и при этом простых фреймворков, хотя однозначных подтверждений этому нет.
Есть
Аналогов Gii нет ни в одном современном фреймворке (по крайней мере из коробки в большой четверке).
Это шутка? Этим вещам по 10-20 лет, если не больше.Ну я не говорил что это всё вчера появилось, это глава про базовые понятия же.
ЕстьКлассный линк, спасибо.
Аналогов Gii нет ни в одном современном фреймворке
Попробуем сделать выводы?)
Это шутка? Этим вещам по 10-20 лет, если не больше.Больше. Agile скоро 20, остальные старше. ООП — 52 года.
А системы контроля версий — это, как говорится, было бы смешно, если бы не было так грустно. Вы даже не представляете, сколько до сих пор существует айтишников, которые не умеют ими пользоваться.
Это не столь важно. Даже в рамках PHP объектная парадигма доступна с начала 2000-х годов, MVC (в вебе) стартовал годом позже с подачи DHH и его рельсы. Другое дело, что пока у тебя сайт представляет собой 20 php скриптов, тебе этот MVC не особо-то и нужен. Дак и на C можно в объектном стиле писать, структы есть же? Значит можно. Я особо не интересовался, есть ли там инкапсуляция и прочие ништяки полноценного ОО подхода, но по крайней мере зачактки уже есть, а это 1972 год.
А вот переход от сервер сайд рендеринга к клайент сайд рендерингу — это реально революция в вебе, но автор этому посвятил одну строку в своей статье. Из этого делаю вывод: реальность современного веба автор не понимает, масштаб изменений не оценивает. Смысл тут дальше что-то обсуждать?
А вот переход от сервер сайд рендеринга к клайент сайд рендерингу — это реально революция в вебе, но автор этому посвятил одну строку в своей статье. Из этого делаю вывод: реальность современного веба автор не понимает, масштаб изменений не оценивает. Смысл тут дальше что-то обсуждать?
Системам контроля версий около 50-ти.
Я работал с SCCS, которая была предком CVS и родилась еще в недрах bell labs где-то в начале 70-х
Просто системы контроля версий реально решают проблемы тех проектов, где несколько программистов.
А где разработчик один — это больше вопрос привычки и удобства.
Я работал с SCCS, которая была предком CVS и родилась еще в недрах bell labs где-то в начале 70-х
Просто системы контроля версий реально решают проблемы тех проектов, где несколько программистов.
А где разработчик один — это больше вопрос привычки и удобства.
А системы контроля версий — это, как говорится, было бы смешно, если бы не было так грустно. Вы даже не представляете, сколько до сих пор существует айтишников, которые не умеют ими пользоваться.This! Собственно, потому и упомянуто.
Ну я не говорил что это всё вчера появилось, это глава про базовые понятия же.
для претендента на вакансию web-разработчика сейчас недостаточно навыков десятилетней давности (какая неожиданность!)
Десять лет назад веб-разработчик, незнакомый с ООП, MVC и методологией Agile мог работать в лучшем случае каким-нибудь битриксоидом на екоммерсе. Как вы себе представляете веб разработку на PHP в процедурном стиле? Вы хоть откройте учебник Шлосснейгла (2004 год, если что) и ознакомьтесь с его содержимым, прежде чем статьи писать.
Десять лет назад веб-разработчик, незнакомый с ООП, MVC и методологией Agile мог работать в лучшем случае каким-нибудь битриксоидом на екоммерсе.Крайне спорное заявление. Вы в целом что хотите сказать, что ООП знать не нужно или чего?
Как вы себе представляете веб разработку на PHP в процедурном стиле?А где я писал про процедурный стиль? Речь о том, что многие сегодняшние модные «JS-кодеры», любящие рассуждать на тему что круче TypeScript или ES6+, не в состоянии при этом без гугла внятно ответить чем, например, объект в том же JS отличается от примитивного типа. Или, является ли функция объектом. Собственно, лишь для того чтобы у читателя эти понятия лучше закрепились в голове эта отсылка и сделана.
Вы хоть откройте учебник Шлосснейгла (2004 год, если что) и ознакомьтесь с его содержимым, прежде чем статьи писать.Зачем?
Я говорю, что статья в целом не отвечает на вопрос, поставленный в заголовке: а именно познакомить человека с современной веб разработкой.
ООП, MVC — это все было и десять, и двадцать лет назад. Ну, правда, сложно представить себе человека, занятого в IT и не знакомого с этими концептами. PHP7, да равно как и RoR нынешний мало чем отличаются от самих себя в 10 летней ретроспективе. Так ли важны тайп хинты и декларация типа ретерна? Наверное, нет.
А вот самому важному, REST API, вы уделили одну строку (sic!). А ведь тем временем это самое важное изменение в вебе за всю его историю. Это смена парадигмы в целом: раньше мы имели сервер сайд рендеринг с js (который в принципе мог быть отключен) для второстепенных задач, то сейчас мы имеем клайент сайд рендеринг, т.е. js вышел на передний план, он значительно превысил в сложности программирование на бэк энде, которое по сути свелось к формированию и отдаче json'а из БД.
На фронте же теперь создаются сложнейшие приложения с полноценным рил тайм рендерингом, которые не уступают возможностям традиционных десктопных приложений. Разве могли бы быть реализованы хотя бы теже гугл документы, трелло или какой-нибудь google docs без современного js? Вот о чем должна была быть статья, что там на бэкенде, PHP или RoR — это вообще уже не важно.
ООП, MVC — это все было и десять, и двадцать лет назад. Ну, правда, сложно представить себе человека, занятого в IT и не знакомого с этими концептами. PHP7, да равно как и RoR нынешний мало чем отличаются от самих себя в 10 летней ретроспективе. Так ли важны тайп хинты и декларация типа ретерна? Наверное, нет.
А вот самому важному, REST API, вы уделили одну строку (sic!). А ведь тем временем это самое важное изменение в вебе за всю его историю. Это смена парадигмы в целом: раньше мы имели сервер сайд рендеринг с js (который в принципе мог быть отключен) для второстепенных задач, то сейчас мы имеем клайент сайд рендеринг, т.е. js вышел на передний план, он значительно превысил в сложности программирование на бэк энде, которое по сути свелось к формированию и отдаче json'а из БД.
На фронте же теперь создаются сложнейшие приложения с полноценным рил тайм рендерингом, которые не уступают возможностям традиционных десктопных приложений. Разве могли бы быть реализованы хотя бы теже гугл документы, трелло или какой-нибудь google docs без современного js? Вот о чем должна была быть статья, что там на бэкенде, PHP или RoR — это вообще уже не важно.
А как соотносится REST с client-side rendering? Если там будет не REST, а XMLRPC, что-то поменяется в вопросе «client side rendering»?
Парадигма REST это классная идея, серьёзно. Но описывать это всё в статье про fullstack… Разбирать её проблемы и прочее? Это на главу отдельную потянет. И если каждый вопрос так разбирать, это будет уже не статья про фулстек, а книга «как стать разработчиком». А ещё, строго говоря вы не правы — до сих пор создаются приложения где никакого REST нет и быть не может, просто потому, что основные принципы не соблюдаются. То есть это API, но не следующее строгой концепции REST.
А как соотносится REST с client-side rendering? Если там будет не REST, а XMLRPC, что-то поменяется в вопросе «client side rendering»?
Вы себя нормально чувствуете? Я вам говорю, изобрели автомобиль. 10 лет назад ездили на лошадях, а сейчас ездим на автомобилях. А вы меня спрашиваете: «А причем здесь Форд?» Да не причем, протокол и формат обмена данными может быть вообще любой, хоть плэйн текстом. Это все несущественные мелочи.
Существенно то, что раньше веб страница формировалась на сервере и была абсолютно статичной, то сейчас это все происходит на клиент. Автор этому внимания не уделил, просто перечислив это как одну из «технологий». А меж тем это революция в вебе. Как я уже писал выше:
Из этого делаю вывод: реальность современного веба автор не понимает, масштаб изменений не оценивает. Смысл тут дальше что-то обсуждать?
Смысл тут дальше что-то обсуждать?
Есть только смысл обсудить каким образом это набрало столько плюсиков ))) Тут же вроде технически грамотная аудитория…
Ну, во первых вы комментом ошиблись. Во вторых,
Существенно то, что раньше веб страница формировалась на сервере и была абсолютно статичной, то сейчас это все происходит на клиент. Автор этому внимания не уделил, просто перечислив это как одну из «технологий».А REST-то тут при чём?
Про Sphinx есть, а про великий и могучий ELK стек ни слова.
Интересно, что судя по графику 40% собираются не использовать SPA фреймвок, хотя реальность такова что все вакансии используют один из Angular/React/Vue, даже старичка backbone в них нету… странные данные опроса :) Вряд ли сейчас есть хоть одна вакансия клиентского js без этой тройки фреймворков.
На Angular вовсе не обязательно SPA делать. Как и на React, собственно, хотя он, конечно, больше на это заточен.
В чем выражается большая заточенность React на SPA относительно Angular?
Ну, перечислите, например, как можно применить чистый реакт на странице (пусть даже с Redux), если не считать рендеринг компонентов, описанных на JSX.
Если же, в случае ангуляра, не пользоваться компонентами и не писать свои директивы, всё равно, по сути, у нас всё ещё останется мощный инструмент с десятком возможностей, включая систему событий и привязку данных.
Если же, в случае ангуляра, не пользоваться компонентами и не писать свои директивы, всё равно, по сути, у нас всё ещё останется мощный инструмент с десятком возможностей, включая систему событий и привязку данных.
Если же, в случае ангуляра, не пользоваться компонентами и не писать свои директивы, всё равно, по сути, у нас всё ещё останется мощный инструмент с десятком возможностей, включая систему событий и привязку данных.Можно подробнее?
Двусторонняя привязка данных между моделью и представлением, а также своя система событий есть в AngularJS «из коробки» (встроенные директивы ng-bind и ng-model, очень удобная ng-repeat, механизм $on/$emit/$broadcast). Всё это позволяет работать с любым интерфейсом, описанным в HTML, без всяких SPA, при этом не нужно ничего кроме самого ангуляра к проекту подключать.
AngularJS имеет фундаментальные/неустранимые проблемы с производительностью. Было бы очень недальновидно начинать использовать этот фреймворк в наши дни. А вот Angular 2+ это совсем другое дело.
Если нужен только реактивнй рендеринг HTML шаблонов и также например обработка onlick DOM-подобных событий, то существую гораздо более легковесные и тоже быстре решения чем AngularJS или React.
Механизмы $on/$emit/$broadcast лучше не использовать тк они завязаны на scope, понятие которе существуют только в AngularJS, потом задолбаетесь переезжать на другой фреймворк. Лучше уже тогда просто задействовать просто EventEmitter, но лучше работать без событий или хотя бы их типизировать что сделать не так просто. События вносят неявность во взаимодействие сущностей.
Если нужен только реактивнй рендеринг HTML шаблонов и также например обработка onlick DOM-подобных событий, то существую гораздо более легковесные и тоже быстре решения чем AngularJS или React.
Механизмы $on/$emit/$broadcast лучше не использовать тк они завязаны на scope, понятие которе существуют только в AngularJS, потом задолбаетесь переезжать на другой фреймворк. Лучше уже тогда просто задействовать просто EventEmitter, но лучше работать без событий или хотя бы их типизировать что сделать не так просто. События вносят неявность во взаимодействие сущностей.
Второй ангуляр может и лучше, но его использовать без Node уже становится затруднительным, у них там минимум половина примеров даже в документации заточено на механизмы export/require. AngularJS для меня ценен именно возможностью писать хоть в блокноте.
Что касается производительности, это очень холиварная тема, я в целом с вами не согласен, потому что регулярно наблюдаю как тормозят и криво работают проекты моих коллег, написанные на React и новых версиях Angular (в частности во второй). При этом код на AngularJS по своему «монолитен», а проблемы с производительностью начинаются только если вам приходится работать с большими объёмами данных (1000+ объектов в выдаче API). Если у вас есть конкретные примеры, подтверждающие ваши слова, приведите их.
Что касается производительности, это очень холиварная тема, я в целом с вами не согласен, потому что регулярно наблюдаю как тормозят и криво работают проекты моих коллег, написанные на React и новых версиях Angular (в частности во второй). При этом код на AngularJS по своему «монолитен», а проблемы с производительностью начинаются только если вам приходится работать с большими объёмами данных (1000+ объектов в выдаче API). Если у вас есть конкретные примеры, подтверждающие ваши слова, приведите их.
а проблемы с производительностью начинаются только если вам приходится работать с большими объёмами данных (1000+ объектов в выдаче API).Это неверное суждение. Падение производительности там завист от количества вотчеров, если вотчеров немного, то не важно сколько данных было скачано.
регулярно наблюдаю как тормозят и криво работают проекты моих коллег, написанные на React и новых версиях Angular (в частности во второй).Криворуких разработчиков всегда хватало. Дело в том что AngularJS не предоставляет нормальных возможностей управления change detection механизмом, а современные фреймворки предоставляют (хотя не уверен насчет Vue который в этом плане считается негибким).
Всем нужен SPA и только на 3-ке этих фреймворков, так что на практике обязательно выходит :)
Не нужны сейчас препроцессоры CSS. По десятилетней привычке тянут из проекта в проект целый зоопарк различного софта.
Альтернативой предлагается CSS-in-JS или просто старый добрый CSS?
Альтернативой чему? Можно как-то конкретнее? Может вы имеете в виду сакральный ритуал
npm install -g sass?Как предлагается писать стили, отказавшись от препроцессоров CSS?
А как их писали до появления препроцессоров?
Чем неудобно?
Открываю я вот «Основы Sass» и вижу:
По факту преимуществ не так уж и много, как можно было бы ожидать. Взамен мы получаем возню с установкой и компилированием. Резко возрастающую сложность правки и необходимость крайне тщательно отслеживать весь набор стилевых правил (навесили пару миксинов на какой-то класс, потом в этом же классе переопределили какое-то свойство, потом заменили в одном из миксинов другое свойство и до кучи подключили отдельный файл css — а потом попробуйте с помощью веб-инспектора разобраться со специфичностью и местоположением правил и быстро всё разрулить).
Ну и самое главное почти все актуальные «основы Sass» вступают в конфликт (или дублируют) с другим талмудом модного веб-разработчика — БЭМом.
- Переменные — реализовано
- Вложенности — дичь!
- Фрагментирование — ненужная фигня выделенная в отдельный пункт
- Импорт — реализовано (ещё фиг знает когда)
- Миксины — ну вот выглядит более-менее полезно (но конечно не для префиксов) но об этом чуть ниже
- Наследование — снова не понятно, зачем практически дублировать «фичи»? чем это отличается от миксинов?
- Операторы — реализовано
По факту преимуществ не так уж и много, как можно было бы ожидать. Взамен мы получаем возню с установкой и компилированием. Резко возрастающую сложность правки и необходимость крайне тщательно отслеживать весь набор стилевых правил (навесили пару миксинов на какой-то класс, потом в этом же классе переопределили какое-то свойство, потом заменили в одном из миксинов другое свойство и до кучи подключили отдельный файл css — а потом попробуйте с помощью веб-инспектора разобраться со специфичностью и местоположением правил и быстро всё разрулить).
Ну и самое главное почти все актуальные «основы Sass» вступают в конфликт (или дублируют) с другим талмудом модного веб-разработчика — БЭМом.
То есть «просто старый добрый CSS», как предположил serf. Я не понимаю, что помешало сразу так и ответить. (Если что, я здесь не принимаю ничью сторону, я просто хочу разобраться)
Постпроцессоры
Очевидно альтернативой препроцессорам которые вам «не нужны».
предлагаете писать все в одном файле а потом быстро ориентироваться в 4000 строк туда сюда? Вложенность, компиляция в один файл, минификация, автопрефиксер — попробуйте что-то выкинуть и сказать что это можно и ручками.
Для Python - самый популярный менеджер это Pip… Но вернёмся к PHP.Вот там и оставайтесь.
Сильный, профессиональный комментарий уровня «Школьник поржал над немодным пыхом»
кому-то пришло в голову, что без строгой типизации в JS жить ну никак нельзя, поэтому мы сейчас имеем то, что имеемМатерого фуллстекера видно издалека.
CoffeeScriptЭту штуку уже не упоминают в приличном обществе. Также как и Gulp/Grunt, Bower и прочие анахромизмы.
PS Полистайте вакансии лидеров рынка и возьмите киворды оттуда.
Порог входа в статью очень высок, даже для ИТ. Понизьте этот порог, до уровня «бабушка с базара, продающая пирожки». Хоть я у кручусь в около-ИТ-шной среде, ближе к сисадминству, все равно смотрел на содержимое, как барашек на новые ворота. Можете даже каждый технолоджи-буллет отдельным топиком рассмотреть, только опять же, чтобы бабушке с базара было ясно. Я например, сколько не пытался усвоить что такое ООП в школе/универе, так остался нулём в этой теме — вывод — преподавали всё время не правильно. Сделайте статьи — и хайпанёте и аудитория спасибо скажет.
А в интернете почитать — не?
Знает ли бабушка где в инете доходчиво написано?
Ну, на эту статью она разве не в интернете наткнулась? Так пусть также поищет по запросу «объяснение ООП»
ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5 даже на википедии высокий порог, для меня это набор слов. Можете дать конкретные статьи «для реальных совковых твердолобых бабушек»?
Сайт1
habr.com/en/post/148015
vertex-academy.com/tutorials/ru/chto-takoe-oop
jsehelper.blogspot.com/2016/01/blog-post_9.html
А вообще, хорошо бы просто какую нибудь книгу по определенному ООП языку прочитать, там все понятно будет. Потому что понять ООП без привязки к языку и без работы с языком и ООП наверное сложно.
habr.com/en/post/148015
vertex-academy.com/tutorials/ru/chto-takoe-oop
jsehelper.blogspot.com/2016/01/blog-post_9.html
А вообще, хорошо бы просто какую нибудь книгу по определенному ООП языку прочитать, там все понятно будет. Потому что понять ООП без привязки к языку и без работы с языком и ООП наверное сложно.
Базовая идея ООП проста, как три копейки: это способ организации кода. В процедурном программировании вы просто сваливали в кучу глобальные переменные, функции и процедуры, а в ООП вы группируете переменные и процедуры для их обработки таким образом, чтобы они не мешали друг другу. А вот КАКИМ ИМЕННО ОБРАЗОМ все это друг с другом группировать — это то самое «высокое искусство», которое можно изучать бесконечно, о котором пишут книги и даже диссертации, и которое вам абсолютно бессмысленно знать, если вы лично не программируете. А вот как начнете программировать — рано или поздно разберетесь.
Да, быть сейчас программистом «на уровне» тяжело. Очень много технологий, от которых нельзя отмахнуться, под предлогом, что это «хайп» или «нафиг нужно». Смотришь вакансии, там не столько знание языков нужно, сколько опыт работы с фреймворками и IDE.
Раньше надо было иметь некоторую базовую подготовку по логике/алгоритмам, немного математики. И знать один-два базовых языка типа C++. И с этим багажом можно было не пропасть.
Не то, чтобы я жалуюсь — наоборот, стало даже еще интереснее, чем лет 20 назад. Но страшновато, честно.
Раньше надо было иметь некоторую базовую подготовку по логике/алгоритмам, немного математики. И знать один-два базовых языка типа C++. И с этим багажом можно было не пропасть.
Не то, чтобы я жалуюсь — наоборот, стало даже еще интереснее, чем лет 20 назад. Но страшновато, честно.
только вот yarn не обертка над npm :(
Изложение получилось достаточно сумбурное, в основном из-за того что непонятно на кого все-таки рассчитана статья — на новоиспеченного джуна или мида/сеньора, который последние 10 лет застрял в легаси.
Многие подходы, технологии, библиотеки уже можно не упоминать в 2019. Либо они на закате, либо ушли из мейнстрима в свою нишу. Это как минимум Bower, CodeIgniter, AngularJS, Zend Framework, Grunt, Gulp, Kohana/Koseven, Browserify, CoffeeScript, LESS, XPath.
Можно отметить что PHP перестал быть платформой по умолчанию для бэкенда, в то же время платформа достигла зрелого состояния и твердо заняла свою нишу.
Чего бы еще хотелось добавить в такую статью (если все-таки ориентироваться на проспавших мидлов/сеньоров):
Что понравилось, это упоминание The State of JavaScript. Имхо это первое с чего следует начать обзор чтобы освежить знания. Особенную ценность представляет динамика показателей за 3 года, по ней можно делать выводы о росте/падении популярности.
Многие подходы, технологии, библиотеки уже можно не упоминать в 2019. Либо они на закате, либо ушли из мейнстрима в свою нишу. Это как минимум Bower, CodeIgniter, AngularJS, Zend Framework, Grunt, Gulp, Kohana/Koseven, Browserify, CoffeeScript, LESS, XPath.
Можно отметить что PHP перестал быть платформой по умолчанию для бэкенда, в то же время платформа достигла зрелого состояния и твердо заняла свою нишу.
Чего бы еще хотелось добавить в такую статью (если все-таки ориентироваться на проспавших мидлов/сеньоров):
- Больше внимания уделить контейнерам, тем более это далеко не только о деплое
- Новые направления для fullstack: Electron, React Native (краткий обзор)
- Mobile first, PWA
- Express, Next.JS, Gatsby
- Чуть больше о TypeScript. Ситуация складывается так, что поверхностные знания нужны даже если не использовать его непосредственно.
- Повышение интереса к функциональному программированию
- Подходы к управлению состоянием (Redux, MobX)
- Просто упомянуть: GraphQL, WebAssembly, HTTP2/3
- Изменения на рынке браузеров
- Актуальные IDE
- Как за 10 лет выросли облачные платформы
Что понравилось, это упоминание The State of JavaScript. Имхо это первое с чего следует начать обзор чтобы освежить знания. Особенную ценность представляет динамика показателей за 3 года, по ней можно делать выводы о росте/падении популярности.
А я считаю, что статья и комментарии, которые ее дополнили — в сумме отлично рассказывают о том, что сейчас творится в мире, куда кто-то хочет войти фуллстэком.
Изложение получилось достаточно сумбурное
Вообще непонятно зачем автор взялся что-то писать, если сам не пользовался большинством из указанных технологий. Просто конспект из интернета? Тогда бы уж потрудился более систематично материал представить, а то набросал в одну кучу шопопало, кучу фреймворков для похапе, но ни одного для других языков, назвал контейнеры, но не упомянул об клаудах и IaaS/PaaS, про базы данных ваще ниче не написал, обозвал Rails извращением (что?) и так далее.
Смешал людей коней, да еще и добавил сюда несколько явно ошибочных/устаревших утверждений да еще и отстаивает эти утверждения в камментах. Дичь какая-то.
Ваш комментарий короче и лучше статьи.
Ещё один стандарт который, вероятно, значительно изменит фронтэнд-разработку уже в ближайшем будущем — Web Components. Очень мощный инструмент и он вам определённо пригодится
Это весьма спорное утверждение, несмотря на внешнюю крутость и полезность данной технологии. Если бы веб компоненты появились во времена царствования jQuery, их преимущество было бы неоспоримо, но в текущей ситуации, я бы советовал сфокусироваться именно на изучении современных фреймворков/библиотек (и возможно только на React, спрос на рынке просто огромный, особенно для фулстеков).
Ситуации с Web Components напоминает мне ситуацию с Web Workers. Последние были введены в HTML5, привнеся вау-эффект схожий с тем, что имеет WebAssembly сейчас.
В результате: в них до сих пор нет поддержки es модулей, более менее удобный импорт возможен только в виде блоба, а дебажить всё это — неописуемое удовольствие занимающее несколько часов.
для мелких проектов не критично что использовать, для больших тебе скажут что использовать
Зачем было просить в начале статьи советов от более опытных товарищей, чтобы потом вступать с ними в пустые споры в комментариях?
Вопрос риторический.
Вопрос риторический.
Пожалуйста, не становитесь фулстек. Мы очень устали собеседовать людей, которые знают все, но не могут посчитать биг О время/память быстрой сортировки, а многие и не знают что это такое.
Корпаратив и онлайн идет в сторону серверлесс, где язык становится не так важен как выразительность, скорость, память и надежность.
Один язык из топ 10 вместе с корменом, go4 — вы уже востребованы.
Знаете дядю Боба, Фаулера, REST API level 1-3 и техблоги ебей/нетфликс/амазон — вас хантят по 3-5 предложений в неделю.
DDD, CQRC, event-driven — и вы уже топ кодер, который левой пяткой деплоит в мультиклоуд пока ручками завариваете себе кофе.
Корпаратив и онлайн идет в сторону серверлесс, где язык становится не так важен как выразительность, скорость, память и надежность.
Один язык из топ 10 вместе с корменом, go4 — вы уже востребованы.
Знаете дядю Боба, Фаулера, REST API level 1-3 и техблоги ебей/нетфликс/амазон — вас хантят по 3-5 предложений в неделю.
DDD, CQRC, event-driven — и вы уже топ кодер, который левой пяткой деплоит в мультиклоуд пока ручками завариваете себе кофе.
>Мы очень устали собеседовать людей, которые знают все, но не могут посчитать биг О время/память быстрой сортировки, а многие и не знают что это такое.
Дык потому что все учат ларавель или че там модно
> Корпаратив и онлайн идет в сторону серверлесс, где язык становится не так важен как выразительность, скорость, память и надежность.
Какое-то противоречие. Если у вас облако, мощность которого можно расширить за 1 секунду, заплатив денег, проблемы скорости и памяти уходят на второй план.
> Один язык из топ 10 вместе с корменом, go4 — вы уже востребованы.
Во всех вакансиях пишут не Java, Java + REST/Spring. Я на java пишу с 1996 года, и «голая» она никому не нужна.
> CQRC
Council for Quality Respiratory Care? Community Quarantine Reform Coalition?
Дык потому что все учат ларавель или че там модно
> Корпаратив и онлайн идет в сторону серверлесс, где язык становится не так важен как выразительность, скорость, память и надежность.
Какое-то противоречие. Если у вас облако, мощность которого можно расширить за 1 секунду, заплатив денег, проблемы скорости и памяти уходят на второй план.
> Один язык из топ 10 вместе с корменом, go4 — вы уже востребованы.
Во всех вакансиях пишут не Java, Java + REST/Spring. Я на java пишу с 1996 года, и «голая» она никому не нужна.
> CQRC
Council for Quality Respiratory Care? Community Quarantine Reform Coalition?
Не думаю, что тут противоречие. Речь больше о том, что сами языки теряют уникальность и в конечной оценке дева есть множество других факторов, которые важней.
> заплатив денег
если маржа невелика, а объемы процессинга огромны, то скалировать надо по делу.
> Java + REST/Spring
Это вторичные навыки, которые приобретаются за недели при должной базе.
Главный навык — это умение (и желание) самостоятельно и систематически учиться.
Если желания учиться нет, но человек обладает уже необходимыми навыками — почему бы и нет. В умелых руках лида может и желание учиться вернуться.
CQRS конечно.
> заплатив денег
если маржа невелика, а объемы процессинга огромны, то скалировать надо по делу.
> Java + REST/Spring
Это вторичные навыки, которые приобретаются за недели при должной базе.
Главный навык — это умение (и желание) самостоятельно и систематически учиться.
Если желания учиться нет, но человек обладает уже необходимыми навыками — почему бы и нет. В умелых руках лида может и желание учиться вернуться.
CQRS конечно.
Не все мечтают работать в большой успешной компании.
Что такое go4?
Что бы оценить шанты найти работу, надо не только посмотртеть количество вакансий, но и выяснить количество кандитатов на эти места. Так что какой-нобудь редкий стек может оказаться более перспективным (и более денежным).
Автор, вы в посте несколько раз написали что будете рады если вас поправят, а в комментариях — вообще не рады. Вы уж определитесь, а то непонятно, поправлять или уже не стоит.
Я рад аргументированным правкам, а не выяснениям в духе «мой язык идеален, а ты про него не написал». Опять же, одно дело — конкретно написать что добавить\исправить, и совсем другое — заявить в духе «да ты явно нуб, написал такую-то чушь». Что тут и происходит в половине веток. Чувствуете разницу?
И да, правки я, разумеется внесу, а некоторые уже внёс. Просто на всё сразу не хватает времени, мне ещё бы поработать, знаете ли.
И да, правки я, разумеется внесу, а некоторые уже внёс. Просто на всё сразу не хватает времени, мне ещё бы поработать, знаете ли.
Хорошая статья, но в ней есть очень большая «ложка дёгтя», а именно фраза про то, что роутинг и шаблонизация на бэкенде это извращения. Я не знаю Ruby, может с ним действительно что-то не так (в чем я сомневаюсь), но очень хорошо знаю Python и активно использую в своих проектах шаблонизатор Jinja2. И, исходя из своего опыта, могу выделить три способа формирования HTML-кода страницы, применяемых в современной веб-разработке:
Каждый способ имеет как свои плюсы, так и минусы, и выбирать надо исходя из поставленной задачи, а не потому что «так модно» или «так все делают».
- Страница формируется с помощью шаблонизатора на сервере и уже готовый HTML-код отдается клиенту. У такого способа есть ряд преимуществ: клиенту не надо тратить ресурсы, на составление итогового кода самому; данный код может быть на сервере кэширован (частично или полностью) например, с помощью Redis; отдаваемая страница лучше индексируется поисковыми системами (но тут зависит от поисковой системы, по слухам, кто-то уже и JS-умеет обрабатывать).
- Страница формируется уже клиентом, используя фреймворк (например, Vue), а с сервера запрашиваются только данные через API (REST, JSON-RPC и т.д.). У данного подхода есть свои плюсы, например, уменьшение трафика при обмене данными с сервером.
- Третий способ это комбинирование первых двух, когда части HTML формируются на сервере и могут передаваться уже в процессе клиенту, либо когда первичная страница формируется на сервере, но итоговая «сборка» происходит на клиенте с помощью фреймворка.
Каждый способ имеет как свои плюсы, так и минусы, и выбирать надо исходя из поставленной задачи, а не потому что «так модно» или «так все делают».
Проблема многих разработчиков — обязательно использовать всё новое, «ведь оно же новое! Оно не может быть хуже!». Отсюда появляется тонны всего этого хлама, который потом тормозит на сервере и в браузере.
Запомните — не всё новое=лучшее. Мозг тоже надо включать, у многих он отсутствует, или выглядит как у блондинки «ааа, новьё завезли! надо срочно использовать! даже если нафиг не нужно!».
Запомните — не всё новое=лучшее. Мозг тоже надо включать, у многих он отсутствует, или выглядит как у блондинки «ааа, новьё завезли! надо срочно использовать! даже если нафиг не нужно!».
С точки зрения, озвученной в предыдущем комменте, все было бы хорошо — на ассемблере можно сделать все что угодно и любую задачу решить. И хайпа не было бы уже лет 50. И тратить время на изучения новья не надо — прошел курс в универе и всю жизнь используй, а освободившееся время и деньги, уходившие на самообразование можешь тратить на хобби и семью. Рай. А мы — в аду.
Видимо надо было добавить тег «ирония». То что вы пишете — понятно подавляющему большинству, именно поэтому, за редким исключением, на ассемблере никто не пишет уже многие десятилетия.
Да, можно. Можно и сегодня бэкенд на ассемблере писать.
Вопрос только в удобстве и в затратах временных и трудовых ресурсов на это.
Другими словами, нельзя.
Если задача — быстро-быстро в продакшен, а если проект взлетел и надо оптимизировать, потом уже перепишем на чем-нить получше. Вот с такой задачей ассемблер не справится, а именно в эту сторону идет подавляющее количество задач.
Какая-то очень поверхностная статья без общего понимания технологий, которые описываются.
Некоторые примеры некорректны, а некоторые вставлены вообще без понимания того, что они делают.
Некоторые примеры некорректны, а некоторые вставлены вообще без понимания того, что они делают.
Если еще раз коснуться темы bower — разработчики предлагают заменить его не просто от скуки, а из-за серьезных проблем с безопасностью. Возраст этой информации относительно небольшой, но и не сказать, что свежий. С учетом заголовка статьи — не приведут ли указанные в статье рекомендации «сонного человека» в тупик?
Тестирование — отдельная большая тема. Чаще всего под этим подразумевается т.н. юнит-тестирование. Суть идеи легко понять на простом примере. Создавая тест вы пишете некую обёртку, которая выполнит одну из ваших функций и проверит ожидаемый результат. Затем, когда вы поменяете что-либо в другой функции, от которой зависит первая функция, чтобы проверить, что изменение ничего не сломало — вам достаточно запустить созданные ранее тесты. Надеюсь понятно, насколько это может быть полезно в большом проекте.
Кажется, здесь немного искажено понятие юнит-теста. Его суть в проверке одной конкретной функции, на которую пишется тест. Если у этой функции есть другие зависимости, то вместо них желательно «подсунуть» фэйковые реализации — мок или стаб.
Под описание в статье больше подпадает интеграционный тест.
Мне всегда думалось, что серьезный бекенд это либо JavaEE либо Spring.
Там fullstack разработчики менее востребованы.
По-вашему, какой антоним у «серьезный бекенд»? «смешной»?
IMHO на любом языке можно написать хороший бэкенд. Зависит от задачи.
На чем там бэкенд у ютуба, фейсбука, вк, твиттера?
IMHO на любом языке можно написать хороший бэкенд. Зависит от задачи.
На чем там бэкенд у ютуба, фейсбука, вк, твиттера?
Т.е. какой нибудь Facebook, написанный на php — это «несерьезный» бэкенд?
Не встречал стартапов на Java, скорее всего их очень мало.
Не стоит путать энтерпрайз с бэкендом.
У фейсбука сильно перепиленный PHP, насколько я знаю, ибо производительности обычного им не хватило.
Пожалуй именно «кровавый энтерпрайз» я вложил в понятие «серьезный бекенд».
Думаю справедливо считать энтерпрайз подвидом бекенда :)
Пожалуй именно «кровавый энтерпрайз» я вложил в понятие «серьезный бекенд».
Думаю справедливо считать энтерпрайз подвидом бекенда :)
Пожалуй именно «кровавый энтерпрайз» я вложил в понятие «серьезный бекенд».
Думаю справедливо считать энтерпрайз подвидом бекенда :)
Так вот. Кровавый энтерпрайз ВСЕГДА будет консервативным, поскольку в нем пишутся продукты, которые работают как минимум несколько лет, как в среднем лет 10, и как максимум десятилетиями.
Поэтому чтобы не написали, через некоторое время там будет легаси. Потому что энтерпрайз просто не успевает.
Поэтому в ентерпрайз нужно что-либо более-менее стабильное.
Сейчас в ентерпрайзе разрабатывается много вещей на ноде, котлине, тайпскрипте, питоне и так далее. Но подавляющее большинство вещей все еще работают на java, потому что java была на самом хайпе лет 5-8 назад.
Через 5-8 назад кровавым ентерпрайзом будет текущий хайп, а хайпом будет что-то другое.
Поэтому серьезный бэкенд меняется каждый год, но с запозданием в 5-10 лет.
Потому что Java все таки старая(не значит что плохая). А на сколько я понимаю, стартапы — это обычно что то новое, прорывное. И они в своих продуктах не будут использовать неновое и непрорывное.
Если писать код с нуля, то Java, возможно, не лучший выбор. Да, она действительно старая, а, точнее, консервативная. Нововведения в языке и JVM вводятся очень медленно. Философия «Write once, run everywhere» таки накладывает свои ограничения. Есть модный Kotlin, но от ограничений JVM он все равно не спасает.
По поводу PHP, хотя по комментам, его тут не любят
Полезный ресурс phptherightway, про современную (более-менее) разработку на PHP
Не упомянут PSR, а его знать обязательно, в частности codestyle, т.к. ему сейчас следуют все
Symfony уже достаточно давно стандарт в отрасли. Несмотря на то, что это фреймворк, он хорошо декомпозирован на независимые компоненты
Самые популярные:
- HttpFoundation, обертка для работы с HTTP запросами
- Console, библиотека для работы с CLI, тот же самый composer под капотом содержит именно ее
- Process, для запуска процессов в системе
- Yaml, работа с yaml, используется в phpunit например
Насчет популярности Laravel, вот тут есть описание, что из Symfony там используется: Console, CssSelector, Debug, DomCrawler, Filesystem, Finder, HttpFoundation, HttpKernel, Process, Routing, VarDumper. Это просто самый популярный фреймворк на базе компонентов symfony, как обычно пишут — "с более низким порогом вхождения" (хотя ИМХО, не соглашусь). Так что здесь надо понимать откуда ноги.
Автор попутал много чего из раздела про Laravel
это реализация ActiveRecord, к «модели из концепции MVC» это не имеет отношения
автозагрузка классов существует уже кучу времени
существует почти в любом фреймворке и в виде отдельных реализаций
там и так используется куча компонентов Symfony, да и их отдельно в любом проекте можно использовать при желании
такой формат есть вроде у всех современных фреймворков, да и вообще можно подключить любую библиотеку к любому проекту и сделать бридж чтоб ее использовать
CodeIgniter и kohana — скорее пациент мертв, чем жив
Да и вообще странный fullstack судя по статье — только backend и frontend делает. А как-же мобильные приложения? Добавить к этому списку Apache Cordova/PhoneGap и уже stack будет более full. Ну и простенькую СУБД спроектировать для такого специалиста не должно стать проблемой, про это как-то не рассказано
Eloquent ORM для работы с БД и создания моделей (речь про модели из концепции MVC)
это реализация ActiveRecord, к «модели из концепции MVC» это не имеет отношения
механизм автоматической загрузки классов PHP без необходимости подключать файлы из определений в include
автозагрузка классов существует уже кучу времени
миграции (система управления версиями БД)
существует почти в любом фреймворке и в виде отдельных реализаций
могут использоваться компоненты Symfony
там и так используется куча компонентов Symfony, да и их отдельно в любом проекте можно использовать при желании
есть свой формат пакетов, которые позволяют создавать и подключать модули Composer к приложению на Laravel
такой формат есть вроде у всех современных фреймворков, да и вообще можно подключить любую библиотеку к любому проекту и сделать бридж чтоб ее использовать
CodeIgniter и kohana — скорее пациент мертв, чем жив
Да и вообще странный fullstack судя по статье — только backend и frontend делает. А как-же мобильные приложения? Добавить к этому списку Apache Cordova/PhoneGap и уже stack будет более full. Ну и простенькую СУБД спроектировать для такого специалиста не должно стать проблемой, про это как-то не рассказано
Eloquent ORM… это реализация ActiveRecordДа, это очевидно, но также очевидно, что используется ORM, в основном, в моделях, о чём тут и написано.
существует почти в любом фреймворке и в виде отдельных реализацийРечь про реализации «из коробки». У самых популярных фреймов, таки да. У какого-нить Slim — есть такое?
CodeIgniter… скорее пациент мертв, чем живТам есть линк на статистику прошлого года, которую составлял вовсе не я.
Немного некорректное сравнение выходит — Slim это микро-фреймворк, хотя в нем вполне можно использовать ту же самую Eloquent, как и в любом другом микро-фреймворке
Так как автор не стал писать про Python в виду недостаточности знаний, немного напишу про этот язык и используемые фреймворки, может для кого-нибудь будет полезным. Тем, кто по какой-либо причине еще его не знает, а возможно даже обходит его стороной, хочется посоветовать, все-таки, присмотреться к этому языку получше. Я сам очень долго не хотел его изучать, и причина была не как у многих: «фу, да там все через отступы», а в том, что приводя плюсы питона (да простят меня люди говорящие «пайтон») обычно называют лаконичность языка. Часто приводят фразу в духе: «что на си занимает 100 строчек кода, в притоне это займет 10». Вот эта «простота» отпугивала, особенно после C++ и любимого С#. Казалось, что язык больше для «домохозяек» и людей не умеющих программировать на нормальных языках с нормальной типизацией, да и вообще язык только для скриптов. Я никогда так не ошибался! :) Язык очень мощный, невероятно удобный, который можно применять во многих областях. Я не знаю ни одного человека, перешедшего с PHP на питон, и который после этого опять хотел бы вернуться к PHP. Это я все к чему веду: питон отличный язык для того чтобы создавать на нем бэкэнд. Ну а теперь непосредственно про фреймворки… Для начала надо определиться: какой сервер нам нужен блокирующий или неблокирующий. У каждого из них есть плюсы и минусы. Неблокирующий сервер чаще всего используют для веб-сокетов, но на нем можно писать и обычные сайты, способные одновременно обрабатывать большое количество подключений. Но при работе с такими серверами надо помнить, что все подключения крутятся в одном «общем цикле» и блокировка этого «цикла» приведет к полной блокировки всех подключений, в связи с этим все используемые библиотеки должны быть не блокирующими. Среди неблокирующих фреймворков на сегодняшний день я бы советовал использовать aiohttp, есть и другие достаточно популярные такие как Tornado, но все они уступают aiohttp. Что же касается блокирующего фреймворка, то тут выделяется Django. Он подходит для людей, которые любят чтобы все было в одном флаконе и желательно сразу. Django уже «из коробки» включает в себя и шаблонизатор, и ORM, и многие другие удобные библиотеки. Но если Вы, как и, я любите выбирать библиотеки для каждой задачи свою, то тогда советую использовать Flask, а все остальные библиотеки уже настраивать под себя. Шаблонизатор чаще всего используют Jinja2, это достаточно удобный и распространённый шаблонизатор, с которым если и возникнут вопросы, то ответ можно будет нагуглить очень быстро. Что касается ORM, то в мире питона правит sqlalchemy. Это как пишет создатель peewee (конкурента sqlalchemy): «SQLAlchemy is the gold standard for ORM in the Python world» — и я с ним полностью согласен. Это универсальный и мощный инструмент. Но за все надо платить, в данном случае приходится «платить» сложностью данного фреймворка. Хотя, начать с ним работать можно очень быстро, а вникать в сложности уже в процессе. Есть очень много и других полезных библиотек, полезных при работе с веб, таких как wtforms, beautifulsoup, Pillow и т.д, но тут все уже зависит от конкретного проекта и задач, которые стоят перед разработчиком. Что-то слишком много букв получилось, но, надеюсь, для кого-то будет полезна данная информация.
кому-то пришло в голову, что без строгой типизации в JS жить ну никак нельзя, поэтому мы сейчас имеем то, что имеем
Уважаемый, а как вы представляете себе разработку без строгой типизации в проекте где JS кода на порядок больше чем у Вас? 40 тысяч строк к примеру?
Переход с JavaScript на TypeScript помог нашей фирме найти около 100 проблем, неиспользуемых функций, опечаток и прочего. Никакие процессы code review не помогут добиться того чего даёт строгая типизация.
Из опыта — до 100 тысяч JS нормально разрабатывается, если работает небольшая команда профи которые понимают что делают. Но к этому объему они просто выработают набор правил как все это писать, эдакую типизацию в голове.
Но после перехода на TypeScript я уже на JS ничего больше 100 строк «накидать по быстрому» не пишу вне зависимости от сложности проекта. Банально меньше кнопок надо нажимать.
Но после перехода на TypeScript я уже на JS ничего больше 100 строк «накидать по быстрому» не пишу вне зависимости от сложности проекта. Банально меньше кнопок надо нажимать.
У меня 150к+ строк. Никакого TypeScript, хотя признаю, бардак имеется, но это не результат используемого языка, это скорее из-за того что код в разное время писали разные люди, а раньше не было какого-то единого кодестайла. В результате некоторые функции дублируются, некоторые надо переписать.
Уважаемый автор. Попробуй перечитать спокойно все комментарии и свои ответы.
Сообщество, в общем-то спокойно пытается указать на какие-то неточности или ошибки. Это нормально. Минусы, как известно, ставят охотно. А плюсы — редко.
Так вот. Пробежался по статье. Ну ок, автор пытается объять необъятное. В этом ничего плохого нет. Но вот как только погрузился в комментарии, сразу обращается внимание, что автор практически не умеет воспринимать критику. Практически любое замечание следует оспорить, без (ну по взгляду со стороны) попытки понять другую сторону.
Известно, что на Хабре комментарии — это почти всегда разнозначный (а иногда и больший) источник знаний, по сравнении со статьей. Вот тут то же самое, но автор вместо того, чтобы развивать дискуссии, активно конфликтует практически с каждой точкой зрения. И это прям режет глаза(
Сообщество, в общем-то спокойно пытается указать на какие-то неточности или ошибки. Это нормально. Минусы, как известно, ставят охотно. А плюсы — редко.
Так вот. Пробежался по статье. Ну ок, автор пытается объять необъятное. В этом ничего плохого нет. Но вот как только погрузился в комментарии, сразу обращается внимание, что автор практически не умеет воспринимать критику. Практически любое замечание следует оспорить, без (ну по взгляду со стороны) попытки понять другую сторону.
Известно, что на Хабре комментарии — это почти всегда разнозначный (а иногда и больший) источник знаний, по сравнении со статьей. Вот тут то же самое, но автор вместо того, чтобы развивать дискуссии, активно конфликтует практически с каждой точкой зрения. И это прям режет глаза(
Bower? Он же deprecated. Зачем вы откапываете стюардессу?
Прекращу «откапывать», как только прекращу эту «стюардессу» в каждом четвёртом проекте встречать и в требованиях к фронтэнд-вакансиям.
Просто оставлю коммент чтобы иметь возможность написать чуть позже.
Но могу сказать что меня в том числе и как С/С++ разработчика новые тенденции пугают. Особенно что касается Node.js и того, как люди разленились и пихают его всюду.
В целях эксперимента вчера написал два кодпрува необходимого нам бэкэнда на POCO (!) и Crow (почти Node.js) буквально часов за восемь вечером.
Но могу сказать что меня в том числе и как С/С++ разработчика новые тенденции пугают. Особенно что касается Node.js и того, как люди разленились и пихают его всюду.
В целях эксперимента вчера написал два кодпрува необходимого нам бэкэнда на POCO (!) и Crow (почти Node.js) буквально часов за восемь вечером.
на следующих языках:
Python,
Java
.NET
Node.js (тут неоднозначно, но об этом дальше),
Ruby on Rails
И, конечно же PHP.
А на языках V8 и SpiderMonkey уже ничего не пишут? ;-)
Этот язык называется JavaScript, а не NodeJS. И никак иначе.
Ну тогда уже CommonJS.
Ну автор написал NodeJS. Если бы он написал CommonJS, то я бы против него также протестовал, как вы понимаете.
Поправьте меня, пожалуйста, если я что-то не понимаю. Есть ECMAScript (На данный момент спецификации 262) и его расширения: JavaScipt и, например, JScript(Unity Script), Action Script. Так вот по сути Node.js поддерживает дополнительные keyword'ы для импорта и экспорта переменных и сохранения области видимости. Это все называется системой модулей CommonJS. Почему тогда это система модулей, а не расширение?
Насколько я понимаю, CommonJS это именно стандарт, описывающий механизм использования модулей, а не расширение самого языка.
Да, так наверно даже точнее сказать — это спецификация, которая дополнительно еще объявляет новый функционал (который логично бы было отправить в ECMAScript).
Вопрос не в том что написано в документации по JS, вопрос в том почему это там так определено. Ведь например тот же .Net C++ это не язык отдельный, не реализация, не расширение, не фреймворк и даже не LLVM (по сути) на которой выполняется Managed C++ Code, а как-то все вместе.
Ну это ж JavaScript. Там законы ни для кого не писаны.
Был ECMAScript. На его базе сделали несколько разных «интерпретаторов» (обычно их называют движками, потому что они выполняют больше задач, чем просто интерпретатор кода).
Один из них — CommonJS. Взяли и расширили спецификацию своими доработками. Потом сделали NodeJS на его основе. Но, как это внезапно бывает, NodeJS решили не контрибьютить в CommonJS, а просто отошли от него [тут уместна шутка про лунапарк]. Ну а CommonJS сдохнул. Потому что, внезапно, отошли все.
А вообще я не JS-программист. Не очень разбираюсь в их кухне.
Знаю одно — название языка: JavaScript, а не NodeJS.
Был ECMAScript. На его базе сделали несколько разных «интерпретаторов» (обычно их называют движками, потому что они выполняют больше задач, чем просто интерпретатор кода).
Один из них — CommonJS. Взяли и расширили спецификацию своими доработками. Потом сделали NodeJS на его основе. Но, как это внезапно бывает, NodeJS решили не контрибьютить в CommonJS, а просто отошли от него [тут уместна шутка про лунапарк]. Ну а CommonJS сдохнул. Потому что, внезапно, отошли все.
А вообще я не JS-программист. Не очень разбираюсь в их кухне.
Знаю одно — название языка: JavaScript, а не NodeJS.
Да да. Я там выше написал тоже, в комментарии
В том и вопрос был. Но таки да, Node.js это ни разу не язык.
Тоже ни разу не JS-программист, но таки Node.js + Swagger бывает юзаю как тестовый API для сквозного тестирования.
Тоже ни разу не JS-программист, но таки Node.js + Swagger бывает юзаю как тестовый API для сквозного тестирования.
Хоть и не язык, но его подмножество. Вот про этот код можно однозначно сказать – это Node.js, в браузере такое не запустится:
const fs = require('fs');
fs.readFileSync('hello.txt');а вот этот код будет сугубо браузерным
document.getElementById('button').addEventListener('click', () => {
console.log('clicked!');
});Получается, что Node и браузерный JS это разные подмножества Javascript.
Ну, так первое и есть тот самый CommonJS с помощью которого я сейчас пишу скрипты для mpv.io. И вообще, с точки зрения математики, правильнее будет говорить надмножество. В итоге Javascript будет пересечением множества CommonJS и JS.
document.getElementById('button').addEventListener('click', () => {
console.log('clicked!');
});
Это не конструкции языка, это api DOM и BOM, который браузер реализует для JS движка. JS ничего сам по себе не знает ни о document, ни о readFileSync это все внешнее API платформы, в среду которой он интегрирован. В Ioniс и Electron будут доступные другие API, но язык и движок тот самый.
Язык определяется не только синтаксисом, но и стандартной библиотекой. В этой ситуации стандартные библиотеки у нас отличаются.
P.S. понятное дело, здесь не идет речь о формальном определении термина «язык программирования», а некотором X во фразе «я пишу на X». Можете предложить лучшее слово на место X?
P.S. понятное дело, здесь не идет речь о формальном определении термина «язык программирования», а некотором X во фразе «я пишу на X». Можете предложить лучшее слово на место X?
Node.js это платформа= движок JS V8 + окружение встроенных модулей на c++ и их js оберток. По отношению к движку JS это внешнее API и потому уж никак не может быть расширением языка. Commonjs просто соглашение, он не являеться стандартом и имеет кучу реализаций, вот и node предоставляет свою реализацию, то есть это api платформы как и прочие встроенные модули node и никакого отношению к языку не имеет.
js обертки вокруг с++? orly?!
Ну а как же еще?! Серьезно?! Интерфейс к утилите командной строки?! Нет? С каких это пор JS умеет нативно исполнять C код? Если бы вы сказали С++ wrapper я бы еще промолчал.
Интерфейс к утилите командной строки?! Нет?
Чито? Ничего не понял… котопес какой то…
Нет? С каких это пор JS умеет нативно исполнять C код?
Не знаю, где Вы такое там прочитали? JS это реализация ECMAScript, как язык вообще что то может исполнять, если на то пошло, еще и «нативно»? И как С код в принципе может исполняться нативно, т.е без компиляции в байткод?
Если бы вы сказали С++ wrapper я бы еще промолчал.
Нет, системные модули это JS обертка с расширением некритичного API над native модулями, написанных на C++. Без понятия при чем тут с++ оберткаи над чем там она должна быть…
Чито? Ничего не понял… котопес какой то…
А вы вообще в курсе, чем отличается wrapper от interface? Не удивительно что вы ничего не поняли.
Не знаю, где Вы такое там прочитали? JS это реализация ECMAScript, как язык вообще что то может исполнять, если на то пошло, еще и «нативно»? И как С код в принципе может исполняться нативно, т.е без компиляции в байткод?
Какой-то фарс, вы читать умеете вообще? Я вам поясню, вы путаете интерфейс и обертку. Так вот обертка изменяет и расширяет исходный объект будь то класс или функция то что вы дальше описываете это интерфейс. Есть С++ или С модуль который обворачивает zlib и расширяет пространство команд интерпретатора или виртуальной машины. В случае использования JS + JIT + Node.js это будет виртуальная машина. Для Пайтона будет оба варианта.
Нет, системные модули это JS обертка с расширением некритичного API над native модулями, написанных на C++. Без понятия при чем тут с++ оберткаи над чем там она должна быть…
Так это и есть интерфейс. Но вы почему-то упорно называете его оберткой. Могу рассказать как на самом деле работает обертка. Так как zlib написана на С мы экспортируем ее функции так, чтобы рантайм С++ их понимал и мог исполнять, далее мы можем все это дело точно так же обернуть в Managed С++ и уже его использовать для того чтобы подключить как assembly в C# и вот это будет zlib C# wrapper. Поэтому делаю вывод что вы плохо понимаете как работает Node.js под капотом.
И да, называть это js оберткой на С++, во-первых, крайне неграмотно, во-вторых, потом еще и спорить — это крайне глупо.
Не удивительно что вы ничего не поняли.
Конечно не удивительно. При чем там «утилита командной строки» и к какому это модулю node отсылка? Вообще не вижу смысла в таком наборе слов :) Ладно пусть то интерпретатор командной строки, но все еще при чем тут это в контексте модулей fs и zlib…
Так вот обертка изменяет и расширяет исходный объект будь то класс или функция то что вы дальше описываете это интерфейс.
Эх, ну так и правильно, даже если включать режим паттерннаци, и не обобщать все простонародной «оберткой» (ведь это очень важно в этом треде), а говорить о паттерне обретка. Модуль верхнего уровня на js расширяет и изменяет api и далеко не весь api встроенных модулей реализован на с++ и прокинут только интерфейс на него в VM, ничего больше. На с++ реализовано только низкоуровневые части, куча api написано в нем на js, то каким боком эта часть на js будет интерфейсом, а не оберткой по отношению к субмодулю на с++? Был бы то интерфейс, то никакого дополнительный функционала в js модуле не было реализовано. Будем открывать js модуль того же fs с репозитория node? Наличие надстроек над API, импортируемого из с++ субмодуля, и всяких хелперов уже никак по позволяет это назвать интерфейсом и как раз попадает под ваше «обертка изменяет и расширяет исходный объект».
Ну вот как это уживается?
Так вот обертка изменяет и расширяет исходный объект
это JS обертка с расширением некритичного API
Так это и есть интерфейс. Но вы почему-то упорно называете его оберткой.
С модуль который обворачивает zlib
Чудесно, но что там обворачивает с++ модуль неважно, это внешняя third-party dll и вообще предмета спора не касается. Непонятно чего Вы в этот zlib вцепились.
И да, называть это js оберткой наД С++ [модулем], во-первых, крайне неграмотно
Да ну? Ну тогда открываем (https://github.com/nodejs/node/blob/master/lib/fs.js) и смотрим что это такое обертка или интерфейс…
потом еще и спорить — это крайне глупо.
Согласен ;)
Экий вы тугой. Я даже уже не знаю, как вам объяснить, что в принципе не может быть никакого JS враппера над C++. Вот вообще никак, физически невозможно. Но вы продолжайте, я с удовольствием повеселюсь над тем что вы не понимаете принципа работы вашего же инструмента и не понимаете отличия между binding и wrapper.
=)))))))))) Слушайте, ну это реально смешно. То что вы пытаетесь за уши притянуть JS раппинг C++ объекта говорит лишь о том, что вы ничерта не понимаете, как это работает. Ну серьезно, вам даже в последней ссылке пишут «bindings». То что вы в C++ модуле экспортируете какие-то языковые конструкции в пространство виртуальной машины V8 а потом наворачиваете сверху уже js раппер над этими командами не делает это раппером над C++.
И даже класс который называется Wrappable вас не смущает? Да, этот класс и будет раппером. Но это С++ класс.
Как вы это не понимаете?
И даже класс который называется Wrappable вас не смущает? Да, этот класс и будет раппером. Но это С++ класс.
«v8::Object as platform object is called „wrapper object“.»
Как вы это не понимаете?
У меня такое же впечателение после этой ветки о вас сложилось. И я уже несколько лет являюсь разработчиком Chromium и занимаюсь как раз расширением API V8 для специфических задач. Внезапно, да?Ну печально тогда. Тут есть два варианта: вы в принципе не понимаете как это работает, вы не поняли о чем именно спор. В любом случае я предлагаю вам описать механизм запуска «нативного» C/C++ кода с помощью JS скрипта, назовите это раппером, как хотите. Просто опишите.
Слушайте, очень печально что вы разрабатываете хромиум, раз вы даже в упор не видите что вы скидываете мне ссылку на «V8 Bindings Design». Почитайте, разберитесь и не морочьте голову, недоразработчик, спросите у вашего тех лида наконец.
Какой вы обидчивый. Вы знаете, буду летом в гостях в кампусе гугла — я обязательно байку про вас расскажу, только до этого я не собирался упоминать ваш ник, а сейчас думаю что стоит.
Вот спецом для вас заморочился
Итак идем в папочку ./node_modules/zlib/
Потом смотрим че у нас там:
Итак что мы видим? Файл сборки для
zlib C++ wrapper!
Дальше сами разберетесь или помочь?
Итак идем в папочку ./node_modules/zlib/
cd node_modules/zlib/Потом смотрим че у нас там:
tree├── LICENSE
├── Makefile
├── README.md
├── configure
├── index.js
├── lib
│ └── zlib.js
├── package.json
├── src
│ └── node-zlib.cc
├── test
│ ├── deflate.test.js
│ └── inflate.test.js
└── wscriptИтак что мы видим? Файл сборки для
waf и о чудо!!!zlib C++ wrapper!
Дальше сами разберетесь или помочь?
Простите, а встроенный модуль как-то особенно отлично работает? Какая разница? Даже я вижу (тот человек, который на JS не пишет ежедневно) что там
Спор то с человеком о том что wrapper в принципе может быть только тогда когда код wrapper'a имеет прямой доступ к коду того что он оборачивает.
Вот как-то только тут есть одно упоминание раппера:
Вообще спор напоминает объяснение плоскоземельщику что «Dude, after some amount of mass under the influence of self produced gravitational force any body tends to take the form of a ball!», а он тебе: «I can not see the curve.». Как-то так.
InternalBinding вначале. Или как-то это все внезапно перестало быть байндингом и вдруг стало раппером?Спор то с человеком о том что wrapper в принципе может быть только тогда когда код wrapper'a имеет прямой доступ к коду того что он оборачивает.
Вот как-то только тут есть одно упоминание раппера:
In computing, a binding from a programming language to a library or operating system service is an application programming interface (API) providing glue code to use that library or service in a given programming language.
Binding generally refers to a mapping of one thing to another. In the context of software libraries, bindings are wrapper libraries that bridge two programming languages, so that a library written for one language can be used in another language.
Вообще спор напоминает объяснение плоскоземельщику что «Dude, after some amount of mass under the influence of self produced gravitational force any body tends to take the form of a ball!», а он тебе: «I can not see the curve.». Как-то так.
Нет, CPP модуль это не байндинг, это раппер и модуль экспорта в нод. Байндинги на JS это то что потом будет импортироваться в zlib.js и сам zlib.js. Никаких вопросов с терминологией, никаких рапперов.
Помню как-то забил на хабр когда все начали моргать светодиодами на ардуине. И все такие «IoT!», а ты уже давно пишешь модули ядра и разрабатываешь сложные распределенные программно-аппаратные комплексы. Потом года 3-4 назад все массово кинулись в веб апы и облака, а теперь я спорю о том что есть рапперы и байндинги. Совсем грустно. Разочарован.
Помню как-то забил на хабр когда все начали моргать светодиодами на ардуине. И все такие «IoT!», а ты уже давно пишешь модули ядра и разрабатываешь сложные распределенные программно-аппаратные комплексы. Потом года 3-4 назад все массово кинулись в веб апы и облака, а теперь я спорю о том что есть рапперы и байндинги. Совсем грустно. Разочарован.
РазочарованНу и зря, как по мне. Людей становится больше, отсюда статьи с простыми (для вас) темами. Но это же не значит, что люди с высокой квалификацией куда-то отсюда делись =)
Я не могу понять, или я слишком сложно объясняю, или что.
Тут в принципе не важно как это называется внутри кода на JS. Есть механизм расширения чего бы там ни было. Если бы JS или Python в принципе могли нативно запускать машинный код библиотеки на С/С++, пусть даже объектный, и имели бы прямой доступ к языковым конструкциям этих языков они бы могли считаться рапперами. Так как ни один из них в принципе такого не умеет, то все, что происходит лишь экспортирование дополнительного набора команд для интерпретатора или виртуальной машины. затем уже, во время выполнения когда виртуальная машина или интерпретатор видят определенную языковую конструкцию они начинают по этому ключу дергать нативный для себя код. А так как они написаны на С/С++ для них это не проблема. Поэтому это и называется байндингом, потому что мы байндим исполнение какого-то нативного кода к инструкции виртуальной машины или интерпретатора.
Тут в принципе не важно как это называется внутри кода на JS. Есть механизм расширения чего бы там ни было. Если бы JS или Python в принципе могли нативно запускать машинный код библиотеки на С/С++, пусть даже объектный, и имели бы прямой доступ к языковым конструкциям этих языков они бы могли считаться рапперами. Так как ни один из них в принципе такого не умеет, то все, что происходит лишь экспортирование дополнительного набора команд для интерпретатора или виртуальной машины. затем уже, во время выполнения когда виртуальная машина или интерпретатор видят определенную языковую конструкцию они начинают по этому ключу дергать нативный для себя код. А так как они написаны на С/С++ для них это не проблема. Поэтому это и называется байндингом, потому что мы байндим исполнение какого-то нативного кода к инструкции виртуальной машины или интерпретатора.
А почему ".NET" в списке языков вас не смутил?
Вообще, уже давно прошли те времена, когда достаточно было выучить язык, и ты считался программистом. Сейчас нормальный программист должен разбираться, в первую очередь, в экосистеме — среде выполнения, общепринятых библиотеках, технологиях. А язык программирования — дело наживное и учится очень быстро.
=)
В качестве подмножества Lavarel я бы добавил Lumen. Он совсем для чистого бэкенда и один из самых быстрых фреймворков на рынке для разработки REST API.
deleted
Было бы хорошо упомянуть среди необходимых знаний минимальное представление о том, что перед веб-сервером типа «приложение» стоит веб-сервер типа nginx, а где-то в промежутке случается веб-сервер типа unicorn (и всё это три разных вещи, которые зовутся веб-сервером, но решают совершенно различные задачи) — и какие ограничения бывают у этих слоёв.
Фуллстэк должен бы понимать, что делает его приложение, когда в него долбится одновременно два запроса. Он также должен понимать, какая часть системы отдает статику и кто отвечает за поддержание долгих соединений (раз уж про веб-сокеты заходит речь).
К теме про прекомпиляцию стилей и скриптов ещё небольшое дополнение — что нередко после компиляции готовые и минифицированные js/css-файлы отправляются на какой-нибудь CDN.
Фуллстэк должен бы понимать, что делает его приложение, когда в него долбится одновременно два запроса. Он также должен понимать, какая часть системы отдает статику и кто отвечает за поддержание долгих соединений (раз уж про веб-сокеты заходит речь).
К теме про прекомпиляцию стилей и скриптов ещё небольшое дополнение — что нередко после компиляции готовые и минифицированные js/css-файлы отправляются на какой-нибудь CDN.
что перед веб-сервером типа «приложение» стоит веб-сервер типа nginx, а где-то в промежутке случается веб-сервер типа unicorn (и всё это три разных вещи, которые зовутся веб-сервером, но решают совершенно различные задачи)Это ведь про распределение нагрузки всё, верно? А если всё запущено на кластере или на SaaS?
Вероятно тогда балансировщик идет из коробки но не факт что его не нужно настраивать.
В каком-то смысле это про распределение нагрузки, да. Но не только. Скажем, если у вас баласировщик нагрузки не умеет держать долгие соединения, то вебсокеты просто не будут работать. Или будут обрубаться слишком длинные страницы (обыкновенные веб-страницы на 1Mb, например). Дело тут не в нагрузке, а в том, что нужно знать ограничения своих инструментов. Или если вы http-заголовки забываете прокинуть через прокси, то многие вещи в приложении могут отвалиться. Так что переезд из development-режима на production легко может оказаться проблемой даже для ненагруженного сайта.
Но вообще, программисту хорошо бы знать, например, обрабатывает ли инстанс приложения много запросов одновременно, один запрос одновременно или вообще один запрос за время жизни процесса. И проблему непонимания жизненного цикла приложения «балансировщик из коробки» не решает. :)
Но вообще, программисту хорошо бы знать, например, обрабатывает ли инстанс приложения много запросов одновременно, один запрос одновременно или вообще один запрос за время жизни процесса. И проблему непонимания жизненного цикла приложения «балансировщик из коробки» не решает. :)
Статья хорошая, но серверный node.js практически не тронут. Нода ведь придумана для того, чтобы ускорить общение между протоколами — она пока одна из самых быстрых.
Node.js поддерживает все модные СУБД, и хороша для выстраивания АПИ:
- REST — express вам в помощь;
- GraphQL — Apollo или Relay вам в помощь.
Боитесь слабой динамической типизации? Вам в помощь:
- TypeScript;
- Flow;
DevOps — кластеризация, дочерние процессы, контейнеризация — все это умеет node.js из коробки.
Странно что серверная node.js практически не раскрыта (хотя статья про веб), но вот про то что на js можно мобильные приложения писать упомянуто (к слову сомнительное решение без знаний Java или Kotlin). Тогда уж и десктопные приложения стоит затронуть — vscode, discord, skype, atom, hyper и много чего еще, используют electron.js.
Солидная статья.
Как подступиться к fullstack-разработке сегодня, если ты проспал десять лет