Вы уверены, что в JS операции побитового сдвига действительно работают быстрее аналогов (умножения и деления на 2)?
Понятно, что это характерно для Си, но с JS возникают вопросы…
Померил только что — разницы нет.
Кстати говоря. Может, я неправильно понял проблему, тогда поправьте, пожалуйста.
Есть библиотека на C#, нужно пользовать её функции в неуправляемом коде.
В таком случае берем таблицу типов из dll и подключаем эту dll в неуправляемом коде, примерно так:
«Отечественные инновации» — это попилы оборонзаказа? Туда им и дорога.
Ещё бы облегчили сертификацию ПО, тогда наши «чрезвычайно необходимые» предприятия по производству говно-программ по безумным ценам наконец развалятся от собственной бесполезности.
Если не делать ошибок, все будет хорошо, угу. Но это редко случается с девелоперами. :)
Используя JSON.parse(), можно сделать свое приложение не менее безопасным, чем с eval(). Как правило, более безопасным. А цена — небольшая.
Почему вы уверены, что получаете ответ именно от своего сервера?
Почему вы уверены, что ответ от вашего сервера не может содержать атакующего кода?
Код исполняется на клиенте и подвержен разным видам атаки.
Вы должны знать, что отвечать надо с помощью ссылки «ответить» под комментарием. А я вот проинтуичил, что ваш комментарий — это ответ на мой, хотя тред другой. Интуиция — это иногда даже удобно, правда?:)
Я ещё раз повторюсь (видимо, не достаточно полно донес эту мысль в своем первом комментарии), что специалист обязан знать инструменты, которыми пользуется. Это правило применимо к любому специалисту, не только к программисту. Другое дело, что специалист работает с определенными абстракциями, и ожидает, что конкретные реализации этих абстракций на местах не будут вносить изменения в сами абстракции. На то они абстр… ну вы поняли. Я думаю, инженер очень удивится, если получит в руки штангенциркули, которые можно «складывать», и получая отбойные молотки. Это неправильные штангенциркули, их проектировщики не продумали архитектуру, и теперь эксплуататорам приходится переучиваться и быть настороже.
Курс «алгоритмы и структуры данных» независим от языка, на котором будут написаны примеры, потому что абстракция массива проста и понятна, и едина (должна быть) для всех инструментом, использующих эту абстракцию. Если математик складывает массивы, он удивится строке в результате, это WAT. Не больше и не меньше. А спецы пусть мучаются или радуются — их дело. :) Если уж говорить о JS, то мне нравится, что все — строка, типизации нет и т.д., с этим проще работать (до определенного уровня сложности систем, конечно), но над докладом я посмеялся.
Не очень понял смысл поста (вижу, что перевод).
Не думаю, что кто-то из программистов сомневался, что поведение jsc-интерпретатора, продемонстрированное на видео, противоречит спецификации языка. Естественно, результат логичен в том плане, что его можно без сложностей объяснить, последовательно рассмотрев каждую операцию.
Дело в другом, в человеческой логике.
Сложение массивов через оператор (+) — занятие сомнительное, но если язык это позволяет, то логично, что программист ожидает получить на выходе массив, элементами которого будут суммы элементов массивов (в соот. последовательности). Ну или null, если так делать нельзя. Или пустой массив, на худой конец.
Пустая строка в результате — это нелогично ни разу. Хотя и по спецификации.
И так далее.
Понятно, что специалиста, который уже привык пользоваться своим инструментом, привык к подобному «нормальному поведению», такими фокусами не удивить. Более того, он может использовать эти фокусы в реальном проекте, чтобы делать что-то быстрее и проще. Никто не спорит. Но продуманности и логичности языку это не прибавляет.
Хм, транзакционность обеспечивает СУДБ, это ясно. Я говорю о ситуации, когда второй пользователь затрет изменения первого (потому что его взял версию с сервера до сохранения изменений от первого пользователя).
Спасибо за ответ.
Ситуация:
1. Первый юзер забрал карту.
2. Второй юзер забрал эту же карту.
3. Первый и второй юзеры изменили карту на локальных машинах.
4. Первый загрузил карту в БД.
5. ???
Типичная ситуация, надо блокировать каким-то образом доступ к файлам (не средствами СУБД же) или дифать. Как это решается у вас?
Наверное, это какой-то простой вопрос, раз вы не осветили его в статье. Вопрос такой: как происходит взаимодействие пользователей с БД? Допустим, я работаю в MapInfo и хочу получить какую-то карту, поработать с её слоями и сохранить. Как это происходит в вашей случае?
Понятно, что это характерно для Си, но с JS возникают вопросы…
Померил только что — разницы нет.
Есть библиотека на C#, нужно пользовать её функции в неуправляемом коде.
В таком случае берем таблицу типов из dll и подключаем эту dll в неуправляемом коде, примерно так:
Насколько я понимаю, это решает задачу.
Ещё бы облегчили сертификацию ПО, тогда наши «чрезвычайно необходимые» предприятия по производству говно-программ по безумным ценам наконец развалятся от собственной бесполезности.
>>> a + a[[[...], [...]], [[...], [...]], [[...], [...]], [[...], [...]]]
>>> a = [1,2]>>> a
[1, 2]
>>> a[0] = a
>>> a
[[...], 2]
>>> a[1] = a
>>> a
[[...], [...]]
>>> a[0]
[[...], [...]]
>>> a[0][1]
[[...], [...]]
Используя JSON.parse(), можно сделать свое приложение не менее безопасным, чем с eval(). Как правило, более безопасным. А цена — небольшая.
По поводу атак недавно на хабре проскакивало несколько статей про XSS. Очень показательно. :)
Почему вы уверены, что ответ от вашего сервера не может содержать атакующего кода?
Код исполняется на клиенте и подвержен разным видам атаки.
2. Смысл в безопасности.
var jsonObject = JSON.parse("json string");http://www.json.org/js.html
Я ещё раз повторюсь (видимо, не достаточно полно донес эту мысль в своем первом комментарии), что специалист обязан знать инструменты, которыми пользуется. Это правило применимо к любому специалисту, не только к программисту. Другое дело, что специалист работает с определенными абстракциями, и ожидает, что конкретные реализации этих абстракций на местах не будут вносить изменения в сами абстракции. На то они абстр… ну вы поняли. Я думаю, инженер очень удивится, если получит в руки штангенциркули, которые можно «складывать», и получая отбойные молотки. Это неправильные штангенциркули, их проектировщики не продумали архитектуру, и теперь эксплуататорам приходится переучиваться и быть настороже.
Курс «алгоритмы и структуры данных» независим от языка, на котором будут написаны примеры, потому что абстракция массива проста и понятна, и едина (должна быть) для всех инструментом, использующих эту абстракцию. Если математик складывает массивы, он удивится строке в результате, это WAT. Не больше и не меньше. А спецы пусть мучаются или радуются — их дело. :) Если уж говорить о JS, то мне нравится, что все — строка, типизации нет и т.д., с этим проще работать (до определенного уровня сложности систем, конечно), но над докладом я посмеялся.
Не думаю, что кто-то из программистов сомневался, что поведение jsc-интерпретатора, продемонстрированное на видео, противоречит спецификации языка. Естественно, результат логичен в том плане, что его можно без сложностей объяснить, последовательно рассмотрев каждую операцию.
Дело в другом, в человеческой логике.
Сложение массивов через оператор (+) — занятие сомнительное, но если язык это позволяет, то логично, что программист ожидает получить на выходе массив, элементами которого будут суммы элементов массивов (в соот. последовательности). Ну или null, если так делать нельзя. Или пустой массив, на худой конец.
Пустая строка в результате — это нелогично ни разу. Хотя и по спецификации.
И так далее.
Понятно, что специалиста, который уже привык пользоваться своим инструментом, привык к подобному «нормальному поведению», такими фокусами не удивить. Более того, он может использовать эти фокусы в реальном проекте, чтобы делать что-то быстрее и проще. Никто не спорит. Но продуманности и логичности языку это не прибавляет.
Ситуация:
1. Первый юзер забрал карту.
2. Второй юзер забрал эту же карту.
3. Первый и второй юзеры изменили карту на локальных машинах.
4. Первый загрузил карту в БД.
5. ???
Типичная ситуация, надо блокировать каким-то образом доступ к файлам (не средствами СУБД же) или дифать. Как это решается у вас?
Почему именно в офис?