• Сверхбольшие числа на nodeJs, возможно?

    Дмитрий Беляев: где вы взяли int512? Если вы про AVX-512 инструкции, то это не так работает.

    У вас максимум int64 есть, дальше идет представление чисел по частям, причем только целые числа. С дробями уже не выйдет. Векторизация вычислений просто позволяет вам за одну операцию проделать несколько арифметических операций над массивом чисел.
  • Как организовать структуру модульных проектов?

    Виталий: я пока не использую typescript, и в целом мало на ноде пишу.
  • Сверхбольшие числа на nodeJs, возможно?

    Дмитрий Беляев:

    для сервера проще найти обертку над сишными библиотеками. Например вот: https://github.com/justmoon/node-bignum

    да и не видел я еще оберток для ноды, чтоб хотя бы шейдеры позволяли запускать


    https://www.npmjs.com/package/node-webgl
  • Как организовать структуру модульных проектов?

    SOLID это хорошо, но у автора спутаны понятия "класс" и "модуль". Ну мол SOLID легко и просто объяснять на примере языков где есть явные интерфейсы. С модулями такая штука работает так же, но это надо постараться что бы спроэцировать такие вещи как "сегрегация интерфейсов" на модули.

    К примеру... у нас есть модуль "bas64" и нам в одном месте надо только encode а в другом только decode. Согласно принципу сегрегации интерфейсов нам надо два интерфейса для этих двух операций (что бы связанность уменьшить), но с модулями так делать не очень удобно. С другой стороны модуль, который будет использовать наш, может импортировать только то, что ему нужно:

    import {decode} from 'base64';
    
    // magic


    То же про инверсию зависимостей. Вместо "интерфейса" между двумя модулями у нас будет модуль-адаптер. А LSP вообще не поможет автору понять в чем соль, это больше о типах данных, о том что инварианты типов надо усиливать в наследниках... Ну то есть... ни слова про модули.

    Тут больше в сторону структурного программирования стоит ковырять.
  • Сверхбольшие числа на nodeJs, возможно?

    "не нативно" значит что надо поставить либу? ams.js это хорошо, но муторно. Да и если уж про векторизацию вычислений говорить, то почему бы тогда вообще на GPU не переложить?)
  • Как правильно работать с объектами выборки doctrine в Symfony?

    nepster09: ну то есть коллекции - это отдельный пакет, который вы при желании можете хоть с элоквентом юзать: https://github.com/doctrine/collections

    в них много ништяков и с ними стоит отдельно познакомиться. Не нужно думать что доктрина это только ORM.
  • Как правильно работать с объектами выборки doctrine в Symfony?

    Юрий: я не ставлю своей целью популяризацию симфони, так как мое личное мнение что с 2012-ого года ситуация чуть-чуть поменялась и фреймворк остановился в своем развитии (да, появились гварды, появился микрокернел но этого мало и это не так часто используют). А люди, которые привносили новые идеи и трудились над сторонними решениями теперь просто перешли на другие языки.

    nepster09:

    по дальше от всяких там актив рекордов.


    active record вполне себе норм штука, особенно когда у вас уже есть готовая база данных или проектированием модели данных занят DBA какой-нибудь. Для простых проектов тоже норм, проще и быстрее работает.

    Тут проблема просто в том, что люди не знакомы с другими подходами, например что бы не "пихать силой" логику в модель данных, можно завернуть ее в отдельную "сущность", которая бы использовала active record как свои поля и сама отвечала бы за коммит атомарных изменений. Ну то есть row data gateway.

    А когда "в репозитории заворачивают" чаще всего выходит что-то больше похожее на table data gateway (DAO). С этим тоже можно играться и выйдет хорошо. Если знать как и что. А люди не интересуются и частенько за пределы уютного фреймворка не выходят.

    И вот я хочу сменить фраемворк.


    Для подобных решений должны быть ооооочень веские основания. Для бизнеса такие решения должны быть обоснованы причинами в духе "под этот фреймворк уже невозможно найти разработчиков" или "этот фреймворк уже не получает обновлений или суппорта от комьюнити". А мигрировать с одного популярного фреймворка на другой - смысла как бы не особо много.

    Так же, если у вас был active record то вы можете попробовать мигрировать eloquent на symfony или впихнуть Doctrine в Laravel. Весь фреймворк заменять для этого не нужно. У вас проблема исключительно с ORM. А все остальное в целом такое же. Более того, я сейчас подумываю о том чтобы сделать парочку проектов на laravel + doctrine просто потому, что под laravel сейчас пилят более качественные солюшены. До framework-agnostic нормального мы еще не дожили увы.

    В целом же Doctrine как раз позволяет вам организовать все так, что бы у вас о доктрине знало только малая часть системы, инфраструктурный слой (читать Эванса что бы узнать что есть инфраструктура). Можно заморочаться и сделать вообще слоеную гексагональную архитектуру, но это справедливо только для проектов, срок поддержки которых сииильно больше срока поддержки фреймворка.

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


    не нужно, вы же доктрину и туда можете вкрутить быстро. Или вы думаете что слой для работы с HTTP как-то влияет на выбор ORM? Ну или вы ORM собрались просто так менять?

    Соответственно, если я внутри проекта буду использовать методы коллекций, я автоматом привязываю свое приложение к доктрине.


    Эти коллекции абстрактны и не привязаны к хранилищу. Если в один прекрасный день вы захотите заменить доктрину на свой uow + dao к примеру, или сменить реляционную базу на mongodb какую, то вы можете просто реализовать свои коллекции или оставить ArrayCollection. Ну то есть не нужно от них отказываться, в PHP и так нет нормальных коллекций а на массивах далеко не уедешь.
  • Отличия абстрактного класса от интерфейса?

    redtom: это переписанный вариант. Меня тогда занесло чутка.
  • Отличия абстрактного класса от интерфейса?

    Dark Hole: ну вот если так то разница уже не так видна. Точнее не совсем... теперь "виднее" что реализация "дефолтная".
  • Отличия абстрактного класса от интерфейса?

    Dark Hole: не обязательно только для абстрактных классов. Ну то есть если мы делаем один абстрактный класс и наследуем от него другой абстрактный класс - там не обязательно. Для обычных классов поведение в целом одинаковое.

    У меня есть подозрение что "разница" хорошо видна под копотом. Ушел гуглить, аж интересно стало. Особенно в свете default реализаций методов в интерфейсах.
  • Отличия абстрактного класса от интерфейса?

    Dark Hole: переписал "много буков" в другие "много буков".
  • Отличия абстрактного класса от интерфейса?

    пожалуй лучше подходит "объект может имплементить много интерфейсов", как никак это не совсем наследование. Тогда объект с несколькими интерфейсами можно трактовать как композицию типов.
  • Отличия абстрактного класса от интерфейса?

    Dark Hole: вот кратко:

    все упирается в типы. У каждого объекта есть тип. Интерфейс = просто тип, абстрактный класс - тип + реализация. Все довольно просто. Что юзать зависит от того что надо в иерархии типов. Если у вас есть необходимость в базовой реализации (общие правила) то выбираем абстрактный класс. В остальных случаях когда вам нужно определить базовый тип - интерфейсы.

    Наследование вредная штука и его лучше по возможности избегать.

    WebDeveloper2016: Да, плохой пример. Просто не могу сходу в принципе придумать пример наследования с абстрактным классом. Пожалуй надо было вот ту штуку с чатами расписать вместо этого. А так я с вами согласен - лучше объект отдельный для ролей.
  • Знания Junior php разработчика?

    Александр Евгеньевич: ну тип того. Если ко мне придется джун который покрыл хотя бы большую часть этой "програмки", я его возьму. Если буду видеть что где-то недотягивает но какие-то мысли в нужном направлении родить может или просто умеет аргументировать свою точку зрения - это будет означать что за пару месяцев можно будет его подтянуть до этого списочка и брать можно (если человек адекватный и заинтересован конечно)
  • Знания Junior php разработчика?

    Александр Афанасьев: делать фичабрэнчи, например. Каждой маленькой самодостаточной задаче по брэнчу, что бы мастер был продакшен рэди, стабильный и без серьезных багов (маленькие всеравно туда попадут). Тогда вам так или иначе использовать и merge, и rebase и все такое.

    Еще можете поставить себе цель. Использовать git log для того что бы отправлять клиенту отчет о проделанной работе. Или еще чего такого, много полезного можно из git-а выудить. И тогда вы точно научитесь с ним работать.

    А когда много людей подключается - ну это просто свои нюансы, в целом не сильно отличается процесс от работы в одиночку.
  • Рефакторнуть код в ООП?

    Zelyoniy: можно еще отдельно вынести обработку событий в отдельный класс-контроллер который будет дергать компонеты и говорить им что делать. Чтобы вся логика работы с DOM была отдельно, ивенты отдельно и т.д. Разделение ответственности и все такое.
  • Рефакторнуть код в ООП?

    Zelyoniy: объясните тому кто давал задание что "ООП это не классы". Модуль вполне можно считать объектом. Любая хрень инкапсулирующая в себе данные и функции работающие с этими данными является объектом в широком понимании.

    В целом же у вас тут классы можно выделить по компонентам. Компонент работы с формой, компонент счетчик... и все такое.