Действительно, как же связан метод «jsonSerialize» в модели с представлением этой модели в формате JSON)))
Нет, я не вижу ничего нормального, когда такие методы зашиты в модель. Грубо говоря, это аналогично (согласно моему мнению) тому, если в модели был бы метод «convertToHtml» с кусками html в нем. Для приложения на коленке такое, может, и сойдет, но не для чего-то серьезного.
Я много раз спорил со знакомыми, пишущими на Laravel, что модель — это слой данных, который не должен ничего знать о том, в каком формате он будет представлен для пользователя, и все эти «implements JsonSerializable» у модели — это неверно. По мне, так данная статья еще раз это подтверждает.
Так хотя бы вот этот. Это более-менее распространенный, хорошо оформленный стандарт.
сразу с БД отправлять в джаваскрипт
А потом, когда у вас поменяется название поля в БД, вы будете по всему JavaScript-коду его тоже исправлять?
ИМХО, более-менее серьезные проекты должны использовать что-то вроде https://github.com/thephpleague/fractal
А я считаю, что каждый язык должен использовать свой style guide. У SQL свой, у PHP свой, у JSON-API свой. У меня был случай, что мне нужно было перенести проект на другой язык. И что мне, всю схему БД менять? Или добавился второй клиент, использующий JSON-API, написанный на языке с другим стилем именования переменных.
Если, как вы заметили, многие сделали вам замечание по поводу имен полей — так, может быть, действительно что-то не так?
P.S. И да, я считаю, что писать согласно общепринятому для языка стайлгайду — это правило хорошего тона. Для PHP это PSR, для Python это PEP 8, для Javascript это гайд от Airbnb (несмотря на то, что он неофициальный, его придерживаются очень многие).
Я бы не стал называть его просто «каким-то чуваком» =) Я просто привожу в пример реально существующий стайл-гайд, где четко указано использовать «underscore». И я знаю людей и команды, которые придерживаются его (за неимением официального от MySQL или PostgreSQL). По мне, так достаточно нормальный аргумент, если учесть что в поддержку CamelCase я не вижу ничего кроме вкусовых предпочтений отдельных людей.
Не знаю, на мой взгляд, полный объектный маппинг не такая уж и нужная вещь. Может, вы потратите немножко больше времени при написании миграций вручную, но зато можно делать гораздо более гибкие вещи, чем при их автоматической генерации.
Интересно, почему на одну и ту же позицию взяли кандидатов такого несравнимого уровня?) Двое только-только начали программировать, а третий — человек, пишущий парсеры, знающий многопоточность, асинхронность, очереди задач, юнит-тесты и с опытом Python N лет =)
Для примера простой сайт на PHPixie заработал почти в три раза быстрее практически сравнившись со скоростью Phalcon на PHP 5.6, несколько сайтов на Wordpress показали стабильный прирост в скорости в два раза.
Странные какие-то сравнения. В два, в три раза… По сравнению с чем? Какие задачи сравнивались? Какие операции?
Если учесть, что в обычных сайтах основная часть времени уходит на запросы к БД, то непонятно, как смена версии PHP могла это ускорить. Или там на сайтах интегралы численными методами высчитываются?)
Если вы придумали новую иконку и думаете, что нужно к ней подставить небольшую подсказку, то вы не правы.
Я думаю, лучше так:
«Если вы создали новую иконку, и чувствуете, что к ней требуется небольшая подсказка, для того чтобы сделать ее пригодной к использованию — значит, вы спроектировали ее неправильно.»
Иначе белиберда какая-то получается по смыслу.
Написать универсальный движок интернет-магазинов для продажи и написать магазин под свой бизнес (или просто заточить какой-то движок) — это абсолютно разные вещи и по трудозатратам, и по целям. Не нужно их путать.
Конфигурации никому не нужны без платформы 1С. А вот телефоны без интернет-магазина очень даже.
Вы либо не понимаете, что я хочу сказать, либо смотрите на все с какой-то абсолютно другой точки зрения. Где я написал, что 1С-Платформе (или любому полноценному IT-продукту) не нужен маркетинг?
Это только мое субъективное мнение. Я очень уважаю труд менеджеров по продажам, и во многих стартапах он незаменим. Но, имхо, мне больше нравится, когда стартап, который считает себя IT-стартапом, сосредоточен на создании продукта, который сам по себе содержит интеллектуальную ценность и является товаром, который можно продавать.
Например, можно написать Платформу 1С, а можно написать магазин для продажи телефонов, который без телефонов и без их поставщиков — 0 без палки. По-моему, разница существенная.
Чем мне, как программисту, не очень нравятся подобные идеи для IT-стартапов, так это тем, что успех проекта состоит всего лишь процентов на 20 от программирования, а остальные 80% — это беготня с целью договориться с кучей компаний, чтобы они пользовались порталом и реагировали на запросы. В итоге, получается какая-то контора продажников.
Нет, я не вижу ничего нормального, когда такие методы зашиты в модель. Грубо говоря, это аналогично (согласно моему мнению) тому, если в модели был бы метод «convertToHtml» с кусками html в нем. Для приложения на коленке такое, может, и сойдет, но не для чего-то серьезного.
А потом, когда у вас поменяется название поля в БД, вы будете по всему JavaScript-коду его тоже исправлять?
ИМХО, более-менее серьезные проекты должны использовать что-то вроде https://github.com/thephpleague/fractal
P.S. И да, я считаю, что писать согласно общепринятому для языка стайлгайду — это правило хорошего тона. Для PHP это PSR, для Python это PEP 8, для Javascript это гайд от Airbnb (несмотря на то, что он неофициальный, его придерживаются очень многие).
Первая ссылка в google по «sql style guide»:
Странные какие-то сравнения. В два, в три раза… По сравнению с чем? Какие задачи сравнивались? Какие операции?
Если учесть, что в обычных сайтах основная часть времени уходит на запросы к БД, то непонятно, как смена версии PHP могла это ускорить. Или там на сайтах интегралы численными методами высчитываются?)
Я думаю, лучше так:
«Если вы создали новую иконку, и чувствуете, что к ней требуется небольшая подсказка, для того чтобы сделать ее пригодной к использованию — значит, вы спроектировали ее неправильно.»
Иначе белиберда какая-то получается по смыслу.
Конфигурации никому не нужны без платформы 1С. А вот телефоны без интернет-магазина очень даже.
Например, можно написать Платформу 1С, а можно написать магазин для продажи телефонов, который без телефонов и без их поставщиков — 0 без палки. По-моему, разница существенная.