• Тестовое задание моей мечты
    0
    Я регулярно вижу как люди используют линейный поиск по массиву вместо поиска в хэш-таблице и это очень угарно.
    Между тем, ваше утверждение очень забавно. Потому что само по себе его можно трактовать не как «знание теории сложности алгоритмов не так важно», а как «на фронтенде люди не могут пока что освоить JS, куда уж там теория сложности алгоритмов»
  • Симуляция физического мира
    0
    По глупости изначально решил, что метод потенциалов не поможет, но сейчас понял что был не прав. Спасибо.
    А вот касательно безумной точности вы не совсем правы. Когда клацал по чужим симуляторам (которые «решали» эту проблему через соударение) в некоторых случаях добивался точно такого же нарушения. Либо их писали раки, либо это частичное решение проблемы.
    Но у меня задача была по моделированию разных вариантов гравитации для собственного любопытства. Тут именно максимальная точность нужна.
  • Симуляция физического мира
    0
    Ответил выше, я некорректно выразился.
  • Симуляция физического мира
    0
    Уточнение: под столкновением в оригинальном комментарии я подразумевал такое сближение объектов, что их координаты при максимально точных рассчетах должны были рано или поздно совпасть. Самого столкновения не было
  • Симуляция физического мира
    0
    Столкновение никак не обрабатывалось. Строго говоря я не хотел бы вообще их обрабатывать до того момента как пойму, что моя модель корректно работает на гравитации. Про корректность: я ожидал что два идеальных шарика в вакууме (изначально с нулевой скоростью) будут бесконечно мотыляться вдоль одного ограниченного отрезка. За leapfrog посмотрю как оно себя ведет, спасибо.
  • Симуляция физического мира
    0
    Когда писал себе симулятор гравитации обнаружил, что при сближении объектов (столкновение, а не движение по стабильной орбите) все идет в тартары. А именно: объекты после столкновения разлетаются с сильно увеличенной скоростью и нарушением закона сохранения энергии. Ваша реализация точно также ведет себя, если обнулить скорость Луны.
    Есть какие-то способы это обойти?
  • React, Web Components, Angular и jQuery — друзья навеки. Универсальные JavaScript-компоненты
    0
    А что с управлением состоянием? Просто все очень хорошо с реюзом пока у компонентов не появится внутреннего состояния, а вам не понадобится history management.
  • Ключевое слово «var» в Java: пожалуйста, только не это
    –2
    Ну так научитесь именовать чтоль переменные тоже правильно, а не только типы. Или вы аппелируете к тому, что разработчики стандартной либы более правильно именуют типы, чем разработчики вашего проекта переменные?
  • Ключевое слово «var» в Java: пожалуйста, только не это
    +4
    И все же джависты не умеют в корректный нейминг
    FileInputStream theSavingStream

    Теперь я гораздо более хорошо понимаю почему вы считаете, что var это плохо
  • Ключевое слово «var» в Java: пожалуйста, только не это
    0
    А если у вас две переменные (одна InputStream, другая OutputStream), вы как их различать будете? По имени или будете каждый раз бегать глазами к определению переменной?
  • Ключевое слово «var» в Java: пожалуйста, только не это
    +4
    Я не понимаю, почему ошибки не полезут, если мы оставим тип явно. Я также не понимаю, почему ошибки для кейса var будут менее понятными, чем ошибки для кейса createStream().getIP() (т.е. когда мы объединяем цепочку вызовов).
  • Ключевое слово «var» в Java: пожалуйста, только не это
    +2
    Что именно за поток возвращает функция?

    А зачем вам это знать? Я правда не понимаю, объясните
    Я уже не говорю о случаях, когда код был порефакторен кем-то другим (например, человек заменил значение, которое openStream() возвращает — а var остался).

    И что случится плохого, если другой человек поменял возвращаемый тип метода openStream?
    Вы, кстати, не думали о таком концепте: иногда необходимо, чтобы тип переменной был жестко связанной с типом выражения? Например в c++ есть decltype.
    Ясно также, что по-хорошему нужно точнее именовать метод. Но, на мой взгляд, подобные вещи будут приводить к тому, что имена переменных и функций начнут включать в себя ту самую «воду», которая до этого обозначала тип. Особенно когда речь идёт о больших проектах.

    Т.е. по вашему лучше определение переменной в видеFileInputStream fos = ... нежели var inputStream = ...?
  • Ключевое слово «var» в Java: пожалуйста, только не это
    +2
    У var есть польза, но я понимаю людей которые не могут ревьювить шарповый код с обилием varов. Банально разница в том, к какому подходу привык человек. Есть подход, основанный на концепции "важен код, т.е. действия, которые мы совершаем" и есть подход, основанный на концепции "важны типы, т.е. то, с чем мы работаем". Оба подходы имеют право на жизнь и более того, разные подходы по разному ложатся на разные задачи.
    Но прикол в том что отсутствие varа и тех же лямбд (ранее) мешал следовать первому подходу. Тогда как в грамотных руках var и лямбды делают код более читабельным, а не наоборот.
    Можно сравнить код с статьями/книгами. Слишком много воды — трудно уловить суть. Слишком мало воды — мозг либо отвык, либо просто не может слишком долго концентрировать на важных вещах. Оптимальный баланс найти трудно.
  • Ключевое слово «var» в Java: пожалуйста, только не это
    0
    Да, пожалуй случай когда NetUtils возвращает FileOutputStream это действительно весьма странный кейс, когда было бы неплохо увидеть, что тип переменной таки FileOutputStream.
    Но вообще для меня видится довольно странным заявление, что var приносит мало пользы и больше вреда. Это где-то аналогичное тому, что говорить что понижение типа это вредно (типа так: OutputStream unbufOut = NetUtils.getOutputStream(sock);). Зависит от случая к случаю.
    Вообще, в строке приведенной автором для примера я вижу две проблемы корректного именования и проблему того, что зачем-то метод возвращает максимально специфичный класс. Видать джависты не умеют в корректный нейминг и ООП.
  • MongoDB хранение деревьев
    +3
    Во-первых, это зависит от того, зачем вам это дерево нужно. Например, в случае с комментариями к статье — гораздо проще к каждому комментарию добавить айдишник статьи и уже потом сформировать дерево комментариев на приличном языке программирования.
    Во-вторых, нужно учитывать что у документа есть ограничения на максимальный размер
    В-третьих, нужно учитывать что атомарный апдейт документа — это блокировка работы со всем деревом внутри документа.
    В-четвертых, чем не устраивают графовые бд для деревьев?
  • JavaScript и Nginx = nginScript, а HTTP2 в придачу
    –1
    Т.е. только отрисовка UI? А альтернативой им будет C++ под кастомную платформу, более дорогие и редкие разработчики и сложности при разработке связанные с тем, что нету эмулятора устройства? Ну в данном случае это действительно хороший выбор по дешевизне разработки.
  • JavaScript и Nginx = nginScript, а HTTP2 в придачу
    0
    Пруфы?
  • JavaScript и Nginx = nginScript, а HTTP2 в придачу
    –1
    Ну да, еще нужно критическое состояние. По-моему количество веб-сайтов уже является примером критического состояния.
  • JavaScript и Nginx = nginScript, а HTTP2 в придачу
    +2
    Ну давай пройдусь по пунктам:

    1. Приложения в браузере. Ну… Эта, давайте я не буду напоминать лишний раз о том, что приложения в браузере не дотягивают до уровня десктопных?
    2. Node.js — изоморфные приложения, избавление от необходимости дублировать логику, серверный рендринг страниц и прочие плюшки. Популярность понятна.
    3. Операционная система на js? NodeOs что-ли? Это там где взяли linux, выкинули bash и поставили node.js? Мне чё, сделать brainfuck os, чтобы показать абсурдность ситуации? Или может имеются в виду всякого рода веб-оси, которые прикольны только как концепт, но ничего сделать не позволяют?
    4. Плагины для браузера на js? Логично их писать на js, раз веб пишется на js. А давать возможность писать их на C++ — упадет, поломает, уязвимости всякие.
    5. Браузер на JS? Ну давайте, покажите мне браузер на js. Я например пользуюсь Вивальди, у которого UI сделан на react. Да, UI написан на javascript. Глюки пока списываю на то, что браузер не вышел в релиз, однако некоторые артефакты весьма специфичны для глюкавых html/css. Если подключиться к самому вивальди через developer tools, то можно увидеть засранную консоль от ошибок типичных для языка с динамической типизацией. Однако это UI, сам браузер написан на другом языке.
    6. Десктопное приложение на JS? Ну, в эпоху когда люди хотят все онлайн, то написать веб-приложение, а потом упаковать его node-webkit выглядит логичным решением. Или нет?
    7. IDE на JS? О да, я даже знаю одну такую — LightTable. Правда она написана на clojurescript. Просто у людей, которые её писали был выбор между clojure (компилится в java) и clojurescript (компилится в javascript). Так уж получилось, что писать UI оптимальнее с использованием html/css/js. Будет WebAssembly — будет транскомпиляция туда. Работает кстати хорошо, быстренько вроде. Правда консоль опять же засрана типичными ошибками для языков с динамической типизацией.
    8. Микроконтроллеры на JS? А почему вы уверены, что их не фронтендеры программируют? И вообще, как насчет python, rust? Это просто удешевление рынка игрушек для гиков. Гугление показало, что в тех микроконтроллерах характеристики лучше, чем у моего первого компьютера (если что, я молод душой и телом). Рост характеристик позволил писать программы на языках с динамической типизацией. А я таки уверен, что среди фронтенд разработчиков много людей, которым интересны такого рода игрушки. Спрос есть, возможность есть — банальные законы рынка. Но если рассматривать не игрушечный бизнес, то сколько компаний пишут софт для микроконтроллеров на javascript?
    9. Конфиги на JS? Внимательное чтение статьи намекает, что это не javascript, а всего-лишь диалект. Кроме того, ну а чем javascript не хороший язык для скриптов? Ведь он для них и задумывался. Вот приложения на нем писать больно, да, а скрипты норм.

    Вообще, еще можно вспомнить mongodb и couchbase, как базы данных, в которых юзается javascript для юзерских скриптов. Но все это не важно. Веб порождает спрос на javascript разработчиков, javascript разработчики порождают спрос на плюшки, с которыми они могут работать. Вопрос заключается в том, как быстро сойдет спрос на javascript разработчиков, когда появятся реальные альтернативы, а не транскомпиляторы недоделанные?

    Давайте представим гипотетическую ситуацию. Какая-нибудь компания стартует большой проект. У компании есть выбор между двумя языками программирования: каким-нибудь из хороших и javascriptом. При сравнении эти языки оказываются одинаковыми по дешевизне разработки, количеству разработчиков, количеству библиотек и прочее-прочее в рамках этого проекта. Как много компаний вы знаете, которые выбрали или пожелали бы выбрать javascript потому что ну это же javascript — клёвый язык программирования; и разработчики под него хорошие и толковые; и завершим мы проект пораньше, потому что язык такой хороший?
  • JavaScript и Nginx = nginScript, а HTTP2 в придачу
    0
    Я надеюсь WebAssembly и спрос на производительный веб избавит нас от подобного будущего. Распространеность этого языка обусловлена ростом веба и соответствующим спросом на разработчиков, умеющих программировать под единственый язык, заимплеменченный во всех браузерах.
  • Что такое красивый код, и как его писать?
    +1
    fyudanov, matiouchkine
    У каждого из вас просто-напросто разная практика. На деле, множество аутсорсинговых компаний не заморачивается качеством. Как правило долгосрочную поддержку они не оказывают, продукты педалятся быстро, умирают тоже быстро. В итоге в долгосрочной перспективе качество кода не важно. А в краткосрочной перспективе очень сложно объяснять почему нужен рефакторинг. Зато плохое качество кода приводит к тому, что проект не заканчивается раньше чем нужно, что является хорошим фактом с финансовой точки зрения кампании. Ну и оправдываться в стиле «очень много функционала, каждая новая фича пишется труднее» — это нормально и привычно всем. В некоторых компаниях очень заморачиваются на эстимейты, поэтому сделать больше, чем нужно — это неприемлемо для менеджмента.

    Вообще, на разной длительности проекта и с ростом размеров кода нужно придерживаться разных правил. Глупо писать свою инфраструктуру/фреймворк когда вам нужно реализовать одну-две апих. И глупо не писать, когда апих становится много. Прикол заключается в том, что многие разработчики не понимают концепт «рефакторить все время», в итоге получаем легаси и говнокод во все бока.

    Также стоит отметить, что отрефакторить что-то за один раз не всегда получается. А пока ты занимался чем-то другим другой разработчик приходит и дописывает еще херни.
  • Functional C#: работа с ошибками
    0
    Либо выключенный джаваскрипт на мобильном браузере )
  • Functional C#: работа с ошибками
    0
    Если рассматривать в отрыве от валидации, то исключения и ifы просто вносят дополнительную сложность в код, делая его менее линейным и более объемным. Та же Maybe монада — это всего-лишь фокус, чтобы запрятать nullcheckи и сделать код линейным и менее объемным. Никакой магии, никакого профита кроме читаемости и линейности кода. В принципе, это всего-лишь разные подходы для управления control flow. В разных ситуациях получается разные по читаемости код.
  • Functional C#: работа с ошибками
    +3
    Для начала, нужно понимать, что есть разного рода ошибки. Есть исключительные ситуации, а есть валидация. Исключительные ситуации очень похожи на валидацию, но это как разница между интерфейсом и абстракным классом (особенно в C++) — она на уровне семантики (смысла кода). Исключительные ситуации нужны для проверки корректности работы системы. Валидация нужна для проверки корректности данных от пользователя.

    Исключительные ситуации очень хороши, когда вы применяете какую-нибудь разновидность контрактного программирования и убеждаетесь, что входные параметры у метода корректны. Попытался поделить целочисленное число на ноль? Получай исключением в морду. Тут исключения рулят и бибикают.

    Теперь рассмотрим другой пример. После редактирования сущности сервер должен в любом случае провалидировать корректность данных (даже если такие проверки есть на фронтовой части). При этом пользователь должен получить список всех ошибок, иначе его будет раздражать процесс работы с системой. Но вы можете бросить только одно исключение, которое увидит пользователь. Поэтому тут исключения враг. В данном случае очень хорошо работает подход с набором различных независимых валидаторов и собиранием результатов их работы. Тот же ASP.NET MVC/Web API с их ModelState.IsValid — это классический пример данного подхода. При этом при самой валидации нам не нужен стектрейс, а иногда еще и даже вреден — вы же не хотите, чтобы до юзера дошла информация о стектрейсе приложения?

    Но, у подхода с набором различных независимых валидаторов есть проблемы.

    Первая проблема: они независимы друг от друга.
    Пример: у вас есть поля password и confirmPassword. На первое поле навешана валидация «пароль должен быть сильным», на второе поле навешана валидация «confirmPassword должен совпадать с password». Показывать обе ошибки немного странно.

    Вторая проблема: они весьма криво работают как только у вас появляется мультишаговая валидация.
    Пример: юзер аплоадит файл с данными. Сначала вы пытаетесь распарсить файл. В случае неуспеха вам нужно сообщить о ошибке. После парсинга файла вы уже можете валидитировать сами данные. И тут тоже нужно сообщить об ошибки. Как только таких прикольных шагов становится много — код становится очень сильно нечитаемым.

    Третья проблема: они очень плохо работают когда нужно гонять запросы к бд для того, чтобы выполнить валидацию.
    Пример: вы делаете штуковину, которая валидирует изменения нескольких сущностей (банальная система с выгрузкой и загрузкой данных). На одну сущность может выпасть несколько ошибок. Причем, есть некоторые ошибки, которые пожирают другие ошибки. К примеру — есть ошибка «нельзя менять данную сущность при таких-то условиях» и есть ошибки «это свойство сущности нельзя менять при таких-то условиях». Причем под каждое валидационное правило нужно подгружать разнообразные данные, что медленно. Ваш код должен показывать максимум полезных ошибок и работать минимум времени. Соберите синхрофазотрон, короче.

    Прикол заключается в том, что бросить исключение это легко, привычно и требует меньше действих, поскольку интегрировано в язык. Писать набор валидаторов или Result/Validation фокусы — непривычно, да и не всегда так явно и очевидно в рамках языка. Поэтому пока что разумным подходом является смешивание подходов. Но не стоит забывать о том, что требования рано или поздно могут измениться, а времени на рефакторинг не будет.
  • Functional C#: работа с ошибками
    +2
    Возможно вам просто привычнее стандартный подход. На деле пример в статье очень неудачный для пропаганды: он очень простой. В данном примере есть разница между тридцаткой строк почти линейного кода и десяткой строк совсем линейного кода. Поэтому безоговорочно выигрывает привычный код.
    В случае, когда кода гораздо больше и необходима мультивалидация (т.е. нужно вернуть все ошибки) данный подход является более читабельным. По крайней мере, я самостоятельно пришел к такому подходу.
  • Как работает реляционная БД
    +1
    а) файловые системы не любят когда файлов слишком много. Базовый совет по огранизации file storage на основе файловой системы — взять guid или хеш и его части использовать как вложенные поддиректории.
    б) много мелких файлов — гарантия фрагментации
    в) файловая система медленная, поверх неё нужна еще in-memory прослойка. Тупо mapить такое количество файлов не выйдет — их слишком много и они мелкие. Не говоря уже о том, что часть данных не будет помещаться в ОЗУ.
    г) key-value хранилища бывают разные, некоторые с поддержкой транзакций

    Бенч увы не приведу, это только общие рассуждения.
  • Как работает реляционная БД
    0
    Нет, я не утверждаю такого. Я просто хотел сказать, что распарсить запрос — это не вся работа по оптимизации, которая может быть проделана
  • Как работает реляционная БД
    0
    В общем, как и любая программерская дискуссия рано или поздно мы упираемся в наш собственный ограниченный опыт и наши бенчи, написанные под наши кейсы. По-моему тут мы заходим в тупик и дальше дискутировать бессмысленно, ибо никто никому ничего не докажет )
  • Как работает реляционная БД
    0
    Есть таблица, она должна быть не in-memory и персистентной. В неё нужно вставлять много записей временами. MVCC — это дополнительный оверхед на ресурсы, не IO диска, так память. Локи это тоже дополнительный оверхед на ресурсы. Без локов, без mvcc, руками — невозможно в SQL Server, но даст отсутствие лишнего оверхеда. Я об этом говорю, о избавлении от оверхеда вообще
  • Как работает реляционная БД
    –1
    Понимаете в чем фишка. Большая часть программистов, которая работает с базами, делает учетные системы в том или ином виде. А для них сценарии, где пригодны NoSQL базы, ну крайне специфические.

    У меня фишка прикольнее. Я долго не мог осознать как писать решения на чистых key-value storах. Для меня это было на грани «вы че ебанутые, а как транзакции, а как же атомарность, я че руками должен это делать все?». Потом со временем в голову начало приходить, что я могу последовательно переписывая многие вещи отказаться от многих кейсов использования sql. При этом получить профит. Хотя это и трудно моментами продумать. Но я понимаю о чем вы говорите.
  • Как работает реляционная БД
    0
    И что? Это вовсе не означает что будет реальная запись на диск. Вы в курсе как buffer pool работает?

    Мм, т.е. вы таки хотите сказать что in-memory MVCC быстрее чем запись вообще без локов на свежезаписанные записи?
  • Как работает реляционная БД
    0
    Почти все NoSQL базы занимают промежуточное положение. Они вроде как хранилища, но без транзакционности, с другой стороны кеш, но без возможности сброса.

    А что если этого достаточно для реализации транзакционности руками?
  • Как работает реляционная БД
    0
    Вам очевидно, что денормализация требует больше ресурсов при записи?
    Вам очевидно, что денормализация требует больше кода?
    Вам очевидно, что денормализация — не гарантия более быстрых запросов?

    Интересно пишешь. Первые два утверждения абсолютные, третье не абсолютное. «Не гарантия» — т.е. может не быть, а может и быть.
    И отсюда у тебя вывод что в 100% случаев денормализация это вредный совет (да, я там фиксировал на 100%, но вы же не поправили «в редких случаях»). Если бы третье было бы абсолютным, то в совокупности с другими утверждениями по законам логики вывод был бы правильным. Но третье утверждение не является абсолютным (и ты это понимаешь), поэтому вывод неправильный.
  • Как работает реляционная БД
    0
    Механизм обеспечения целостности кеша — сброс и пересбор из хранилища. Сброс кеша сложная задача, но решаемая.
    Механизм обеспечения целостности в хранилище — транзакции и проверки. Это тоже сложная задача, но тоже решаемая.

    А механизм обеспечения целостности кеша и хранилища вместе? На каждую стартующую транзакцию сбрасывать кеш и блокировать его, пока транзакция не завершится? Я только это вижу в качестве решения противодействию нахождении в кеша старых данных.
  • Как работает реляционная БД
    +1
    Если исключить требования уникальности, то будут проданы два билета на одно место и систему быстренько поменяют

    Не надо исключать требование уникальности, я говорил про исключение процесса бронирования.

    С точки зрения UX вообще нельзя ничего блокировать. Поэтому оптимистичная блокировка (легковесный аналог MVCC) + автомерж изменений при конфликтах. Но к тому что делается в базе не имеет никакого отношения.

    По-моему процесс мерджа подразумевает три источника данных: base, this, remote. А это значит, что вам нужно хранить историю изменений. А это дублирование механизмов, заложенных в бд, нет?.. Кроме того, автомердж без подтверждения юзера — плохое решение с точки зрения UX.
  • Как работает реляционная БД
    0
    Ну, да, бронировать тоже нужно атомарно. Просто прикол в том, что в итоге атомарность обеспечивается и приложением, и сервером базы данных. Получается некоторое дублирование.
  • Как работает реляционная БД
    –1
    А денормализация бесплатная чтоли?

    Руками написанная денормализация иногда бывает почти бесплатной. Иногда она бесплатная только на фоне оверхеда от материализованных вьюх
  • Как работает реляционная БД
    –1
    Про то, что есть кеширование планов не знает только ленивый. Native Stored Proc работает только с memory таблицами.
  • Как работает реляционная БД
    –1
    Эм? Если ты хочешь исключить бронирование билета из процесса покупки, то ничего страшного не произойдет. Create Unique решит проблему одновременной покупки билета. Просто твоя система будет говном с точки зрения UX, но это же ничего страшного, да? Зато ты не будешь изобретать блокировки, которые уже релизованы в твоей РСУБД.

    Не отмазывайтесь, отвечайте на вопрос, как вы будете обрабатывать ситуацию возможности открытия двумя разными юзера одной сущности на редактирование? Что вы будете делать, чтобы не изобретать блокировки и mvcc, кроме как положите на эту ситуацию?
  • Как работает реляционная БД
    0
    Или вы заставите одно из них ждать пока 15 минут другого закончатся?

    Да, в этом смысл бронирования. В том, что другой юзер вообще не увидит забронированный билет. А юзер, который забронировал билет — будет видеть время, которое у него осталось для совершения оплаты билетов. Это UX-требование, это то как должна работать система уважающая пользователя

    Вы не понимаете, что только что попытались изобрести механизм блокировок, который уже есть в любой РСУБД? При этом надо будет написать немало кода чтобы реализовать ваш сценарий.

    Да-да, я изобрел механизм блокировок, который есть в любой РСУБД. И это UX-требование и это блять удобно для пользователя. И этим UX-требованием я хотел продемонстрировать, что механизмы блокировок, которые реализованы в бд нужно дублировать мануально в случае существования таких требований.
    Поэтому вместо стандартных блокировок можно использовать то хранилище, которое не навязывает свой механизм блокировок, а позволяет делать что угодно без лишних проблем и просадок по перфомансу. Встречный вопрос: есть сущность в бд, её могут случайно открыть два пользователя конкурретно на редактирование. Как вы будете обрабатывать это и возможные последствия этого?

    Ссылки в студию.

    neo4j.com/docs/stable/query-create-unique.html. Пойдет?