Комментарии 30
Наверняка кто-то задаст этот вопрос(и странно, что издатели не пишут это сразу на обложке): версия ноды в книге 6.5.0 (по крайней мере в английской версии второго издания).
db.query(`INSERT INTO snippets (body) VALUES ( '${body}' )RETURNING id`);За такие примеры книгу нужно сжечь перед прочтением. Понятно, что это простейший тестовый запрос, но ни словом упомянуто о том, почему так делать нельзя — отсюда и берутся в 2018 году разработчики, которые не знают, что такое
Заголовок спойлера
sql injection.
А ведь наглядно можно было заодно показать, как использование Query Builder вроде Knex помогает в этом случае.
Как минимум плохим тоном является указание объектов базы данный без нужных кавычек ("" или `` или []). QueryBuilder нужен для упрощения задачи, но если не понимать что он делает, хотя бы азы, то смысла от его применения будет немного.
Проблема — потенциальная инъекция. Кавычки — это мелочь.
Ой ли, кавычки, например, в PostgreSQL никакая не мелочь
Вы понимаете что такое SQL-инъекция? DROP DATABASE — это ещё не самый страшный вариант. А что кавычки? Подумаешь, запрос ошибку вернёт…
Я понимаю что такое SQL-инъекция и как с ее помощью можно существенно «нагадить». И собственно DROP DATABASE, как Вы сказали, не самое страшное. Есть еще много способов, что помощи них и неправильно выставленных прав доступа можно натворить. Мое мнение — это правильное экранирование, которое и спасет собственно от инъекции. Что и имелось в виду, при ответе, что кавычки как минимум важны.
И как кавычки помогут заэкранировать? Не понимаю…
Пример 1:
WHERE «id» = 10 и WHERE «id» = '10'::integer
Пример 2:
WHERE `id`='asdasdasd\'; DROP… --'
WHERE «id» = 10 и WHERE «id» = '10'::integer
Пример 2:
WHERE `id`='asdasdasd\'; DROP… --'
Поясните, что именно вы имели ввиду, пожалуйста?
Ну вот Вы какие методы устранения уязвимостей на SQL-inject знаете?
Книга — это всегда здорово. Куплю и почитаю. 15 лет уже не читал на бумаге ничего кроме тех. литературы. Но вот это стоит! Потом повешу в рамку. )
КМК, если в одном предложении слова «Книга» и «JS», то здесь что-то не так. Книга по JS устаревает еще до ее выхода с учетом адской нестабильности JS экосистемы, всевозможных фреймворков и технологий. (А про фронтэнд даже читать смешно, там статьи в интернете то не успевают за технологиями, а вы — книги)
Я тоже сперва так подумал, а потом сообразил: в силу специализации часть технологий могла пройти мимо меня, а книга — позволяет быть в курсе того, что я пропустил, без существенных трудозатрат с моей стороны.
Зачем быть в курсе устаревших технологий? Все что сейчас используется в стеке так, или иначе есть на просторах сети в весьма удобном виде, от видео до интерактивных обучалок. Тащить старое в продакшн довольно непонятное занятие, да и если они уже там, то и книга не нужна, Вы с ними, скорее всего итак знакомы. Книги логичнее писать про фундаментальные вещи, алгоритмы, паттерны(и те в мире JS склонны к весьма быстрым изменениям), а не про то, что сегодня/завтра может нещадно устареть. Разбор движка был бы более в тему, но никак не гайд по фреймворкам на JS. Такую книгу завтра откроешь, обнаружишь, что 9/10 пакетов обозреваемых книгой уже на 2-3 релиза впереди, API поменялось с breaking change, а из оставшихся пакетов новые требуют новых версий зависимостей, что опять же ведет к невозможности работать. Я люблю книги, но эта из разряда — «Как провести сегодняшний день (в 2х томах)».
Зачем быть в курсе устаревших технологий?
Для общего развития. Вам не случалось читать книги по BASIC 80-х годов издания? Я читал с удовольствием.
Кроме того, они могли и не устареть. Технологии устаревают с неодинаковой скоростью.
А что в бейсике нефундаментального? Там Алгоритмы, какие то общие паттерны программирования, и все. Как я и сказал, такие вещи можно и нужно паковать в книги. И они будут актуальны и через 10 и через 20 лет. Сказать такое про JS сложно, просто потому, что между теми же ES кучи обратнонесовместимых фич, и даже основы программирования на JS через пару лет будут выглядеть моветоном в глазах более продвинутых коллег.
нефундаментального
Ну, например, методы работы с оперативкой напрямую. Операторы изменения собственного кода (важный приём программирования, когда дефицит оперативки).
Как Вам «удалить строки с такой-то по такую-то и загрузить вместо них содержимое файла такого-то»? Практически верный способ выстрелить себе в ногу, однако ж применяли!
Я уж не говорю о выполнении ассемблерных подпрограмм из оперативки: сперва побайтно её туда загоняем, а потом call <вектор начала подпрограммы>. (call здесь — оператор BASICa, в самом BASICe процедур тогда ещё не было — gosub это другое).
Методы работы с оперативкой, файловой системой как раз таки можно отнести к фундаментальщине же. Разбор фреймворков — нет. Да и стоит учитывать, что в 80-х годах особо не было вариантов для передачи и хранения информации в бытовом варианте, кроме книг то :D
Мне сложно сравнивать BASIC и JS, покуда с первым я знаком только понаслышке, но могу заявить, что сегодня дома отказался работать проект из-за разницы в версии ноды 9.6.1 -> 9.9.0, притом, что на работе таковая 9.8.*
(Обновлялся дома около месяца назад, и она уже(!) устарела и работает некорректно)
Мне сложно сравнивать BASIC и JS, покуда с первым я знаком только понаслышке, но могу заявить, что сегодня дома отказался работать проект из-за разницы в версии ноды 9.6.1 -> 9.9.0, притом, что на работе таковая 9.8.*
(Обновлялся дома около месяца назад, и она уже(!) устарела и работает некорректно)
Методы работы с оперативкой, файловой системой как раз таки можно отнести к фундаментальщине же.
А изменение на лету собственных исходников?
Вы хоть раз слышали, чтобы такое применялось, ну, скажем, последние 20 лет?
Во фреймворках, которые мне не пригодились и никогда не пригодятся, могут быть идеи, которые стоит среверсинжинирить.
Технологии хоть и устаревают, но в данном случае эволюцию никто не отменял. И знание «старых» технологий позволяет понимать преимущество новых, причину, по которой стоит пользоваться новым.
Для примера могу привести конкуренцию Apache и Nginx. В процессе эксплуатации технологии проявляются проблемы, решения которых внедряются в новый продукт.
Без истории невозможно понять ценность того, что имеешь и чем пользуешься.
Для примера могу привести конкуренцию Apache и Nginx. В процессе эксплуатации технологии проявляются проблемы, решения которых внедряются в новый продукт.
Без истории невозможно понять ценность того, что имеешь и чем пользуешься.
Эволюцию никто не отменял, но преимущество ног перед плавниками, при ходьбе, очевидно и без книг. Если целью является рассмотрение процесса эволюции технологии, об этом и следует писать. Тут акцентируется внимание на стеке 2хлетней давности. Книга предполагается как источник знаний, не утрачивающий свою актуальность длительное время, иначе это просто пустой расход бумаги.
В книге версия ноды отличается уже на 3 релиза, и это на момент выхода. На дворе в спецификации уже стейджится es2018, в книге es2015. Плагины по бабелю и все что с этим связано меняются чуть ли не каждые полгода стабильно, перетекая от вендора к вендору. И это только по оглавлению и кускам текстов. Будет ли эта книга актуальна хотя бы к концу 2018? Я очень сомневаюсь.
В книге версия ноды отличается уже на 3 релиза, и это на момент выхода. На дворе в спецификации уже стейджится es2018, в книге es2015. Плагины по бабелю и все что с этим связано меняются чуть ли не каждые полгода стабильно, перетекая от вендора к вендору. И это только по оглавлению и кускам текстов. Будет ли эта книга актуальна хотя бы к концу 2018? Я очень сомневаюсь.
у нас в конторе до сих пор приложение крутится которое только на IE заточено и в новых еджах не работает. Это конечно не javascript, но есть тонны проектов, которые на новые рельсы переводить никто не будет и которые нужно поддерживать. Поэтому знать последний стэк недостаточно, нужно уметь еще в предыдущих версиях разбираться.
Встречал одного шарпера, которому на тестировании дали проект ASP.net4, хотя он работал на ASP.net5. Столько нытья было по поводу устарелости, то что это нельзя поддерживать, что он не говнокодер и т.п. Одного он не понимает — заказчику не нужен идеальный на последних технологиях основанный продукт, ему нужен релиз продукта вписывающегося в дедлайны и содержащий фунциональные возможности которые клиент запросил. Унаследованный код тоже определяет — с каким стэком придется работать, хотя бы какое-то время до переноса всего добра на новый подход.
Встречал одного шарпера, которому на тестировании дали проект ASP.net4, хотя он работал на ASP.net5. Столько нытья было по поводу устарелости, то что это нельзя поддерживать, что он не говнокодер и т.п. Одного он не понимает — заказчику не нужен идеальный на последних технологиях основанный продукт, ему нужен релиз продукта вписывающегося в дедлайны и содержащий фунциональные возможности которые клиент запросил. Унаследованный код тоже определяет — с каким стэком придется работать, хотя бы какое-то время до переноса всего добра на новый подход.
Знакомая ситуация. Но тут мне опять же сложно ответить, ибо я не знаю, насколько инертен мир шарпистов, я там мимокрокодил, только примитивщину писал.
По миру JS могу сказать, что если в проекте есть легаси, это надо искоренять(сейчас активно занимаемся этим в нашей компании). Через полгода-год Вы уже не найдете банально адекватного разраба на такое, и будете либо доплачивать за легаси, либо работать с джунами, которым лишь бы опыт получить.
Проект и не должен быть написан на bleeding edge технологиях, но тянуть в него легаси просто потому что оно там уже было — неправильно, это только свалит проект в еще больший застой, и ни к чему хорошему не приведет.
Соответственно, писать/читать книги по таковым, для меня сомнительное занятие. Я не против такой информации, но опять, повторюсь же, в книжном печатном формате это бессмысленно. Цифровые дайджесты, серии статей на ресурсах — да, но книги — нет.
По миру JS могу сказать, что если в проекте есть легаси, это надо искоренять(сейчас активно занимаемся этим в нашей компании). Через полгода-год Вы уже не найдете банально адекватного разраба на такое, и будете либо доплачивать за легаси, либо работать с джунами, которым лишь бы опыт получить.
Проект и не должен быть написан на bleeding edge технологиях, но тянуть в него легаси просто потому что оно там уже было — неправильно, это только свалит проект в еще больший застой, и ни к чему хорошему не приведет.
Соответственно, писать/читать книги по таковым, для меня сомнительное занятие. Я не против такой информации, но опять, повторюсь же, в книжном печатном формате это бессмысленно. Цифровые дайджесты, серии статей на ресурсах — да, но книги — нет.
Напомните, пожалуйста, что кардинально изменилось в экосистеме nodejs за последние пару лет… даже большинство новых фич языка было реализовано уже в 6 версии ноды, последний мажорный релиз того-же экспресс.жс был около трех лет назад, разве что коа2 из альфы вышла
Это конечно так, но вот релизнутся в этом году декораторы и пайплайн операторы, приватные методы/поля классов, и станут новым стандартом, а в книге про них ничего. Однако они в пропосалах уже больше года висят, и ими свободно пользуются через полифилы/трайнспайлеры того же бабеля. И прочитает человек в середине 2018 такую книгу, увидит запись:
И даже если догадается, по каким кейвордам гуглить, пойдет гуглить, а не искать реиздание за этот год. То что мажорного релиза давно не было, не значит, что это не сломает зависимости с другими актуальными пакетами, то есть человеку так или иначе придется сесть на старый стек, просто потому что он купил такую книгу. Учитывая количество зависимостей в типовом JS проекте, мелкие изменения могут накопиться в немалую кучу. Такой вид информации это просто не книжный формат, вот что я пытаюсь донести.
Если на хабре выпустят статью по технологии 2хлетней давности, все закидают автора камнями, «як же так?!». Но почему то с книгой, за которую человек отдает деньги этот трюк не работает. Однако двойственность стандартов, не?
let string = 'hello' |> trim |> capitalize |> escape;И даже если догадается, по каким кейвордам гуглить, пойдет гуглить, а не искать реиздание за этот год. То что мажорного релиза давно не было, не значит, что это не сломает зависимости с другими актуальными пакетами, то есть человеку так или иначе придется сесть на старый стек, просто потому что он купил такую книгу. Учитывая количество зависимостей в типовом JS проекте, мелкие изменения могут накопиться в немалую кучу. Такой вид информации это просто не книжный формат, вот что я пытаюсь донести.
Если на хабре выпустят статью по технологии 2хлетней давности, все закидают автора камнями, «як же так?!». Но почему то с книгой, за которую человек отдает деньги этот трюк не работает. Однако двойственность стандартов, не?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Книга «Node.js в действии. 2-е издание»