Pull to refresh
37
1
Send message
JSON — JSON.decode/encode

Как у объекта отметить поля игнорируемыми при (де)сериализации объекта? Как переименовать поле? Как добавить метод как сериализуемое поле? Ну и т.д.
Просто на деле часто бывает так: сперва данные АПИ простые и легко перегоняются из и в JSON (ну или xml, не важно). Но рано или поздно наступает момент, когда нужно настроить отображение модели в JSON и правила восстановления модели из него. При этом, не хочется плодить лишние сущности (например, создать отдельный класс для отображения). И если в языке нет готовой библиотеки-маппера с возможностью настройки входного или выходного формата, то можно начать жалеть о своём выборе.

В качестве ОРМ для реляционных баз я увидел это. Но там даже нет отношений. ОРМ для монги умерло.
Как данные-то хранить? Писать запросы и парсить ответы вручную? Так легче взять питон с sqlalchemy и сэкономить кучу времени.

Уточните перед какими решениями вы хотите получить преимущества?

JSON: Ну, например, Jackson для java. Аннотациями можно настроить очень многое. На крайняк, можно написать свой плагин/модуль/datatype и т.д. Часто жалею, что аналогичной либы без зависимостей от веб-фреймворка нет для питона (или я искал плохо).
DB: Например, SQLAlchemy. sqlalchemy-core не реализует ОРМ, но предоставляет унифицированный интерфейс для подключения к БД и приятный DSL для формирования запросов. ORM тоже есть, и он довольно гибкий. Ещё пример — Hibernate или EclipseLink. Помимо кучи фич из JPA (который они реализуют), каждая имеет вдобавок свои полезные плюшки.
Так есть ли удобная либа/фреймворк для persistence-слоя? Будь то ОРМ, просто удобный инструмент для простой работой с реляционными БД или что-то для популярных nosql-баз? Понятно, что хибернейт или алхимия — большие и зрелые проекты, но есть ли в дарте хоть что-то приближённое?

Просто вот такие туторы в 10-30 строк кода хороши только в теории. Всё красиво, ёмко и просто. Но на практике малораспространённые языки/технлогии обычно сосут из-за отсутствия хороших библиотек. Может я и ошибаюсь, но тогда хочется увидеть пример сложного апи-сервиса, а не хелловорда.
Плюс, есть и так куча статей и переводов на эту тему:
habrahabr.ru/post/181988
habrahabr.ru/post/144011
habrahabr.ru/post/144259
и т.д.

Ничего нового в RESTful не появилось, так что статья немного опоздала.
А в чём преимущества перед другими решениями?
Как настроить сериализацию/десериализацию например, для JSON? Как дела обстоят с БД? Есть ли для дарта ORM какие-то? И как у дарта с инструментами для разработки, фреймворками и библиотеками?

Так-то я лучше возьму, например, Eve или просто Flask + плагины, если надо быстро. Или какое-нибудь решение на java/scala. И возьму не только, потому что знаю их хорошо, но ещё и потому что у эти языков очень богатая инфраструктура, есть куча материала в сети и есть приличные IDE для них.
Почему-то не упомянут Torment. Там смерть — важный аспект игры.
В Dark Souls тоже.
Что за глупая привычка в каждой статье по js, где хвалится его экосистема, меряться количеством модулей в репозитории? В npm же есть целая куча модулей-однострочников, философия такая. А ещё есть целая куча мёртвых проектов и дубликатов.
Да, инфраструктура растёт (и это хорошо). Но вот эти графики сразу портят впечатление от статей…
Нет уж, строгая типизация всяко лучше слабой. Неявные преобразования — зло.
Да нет, хороший пример. jQuery в ангуляре почти не нужен. ИМХО, его стоит подключать либо когда нужен какой-то jq-плагин, у которого нет достойных аналогов в виде ангуляр-модуля (или на чистом js), либо когда нужна какая-то прям очень сложная работа с DOM, с которой ангуляровские средства не справятся.
С другой стороны, чаще всего в большом проекте какая-то библиотека всё-равно захочет jq себе в зависимости. А ангуляр умеет детектировать наличие jquery и использовать его заместо jqlite.
jQuery в angular-проект подключают явно не для ajax'а с промисами, ведь в ангуляре есть свои реализации.
А Вы считаете, что чем больше элементов на видимой части приложения, тем это приложение «взрослее»?
CDN — спорное преимущество. Для конечного пользователя он может быть недоступен по разным причинам (блокировка, неполадки на сервере) и тогда веб-приложение сломается.
На проде надёжнее всю статику (js/css) загнать в 1 файл (с таймштампом или чем-то подобном в имени), который и будет лежать в кэше, пока не протухнет или не обновится (при обновлении меняется имя -> никто из пользователей не будет тянуть неактуальную версию из кэша). Плюс, есть много готовых вариантов для сборщиков, чтобы организовать такое.
что вы имеете в IDE, чего по вашему не может Vim и прилегающие к нему плагины

Самое банальное — рефакторинг в большом проекте.
Для хомпейджа достаточно тех же нескольких команд. А юниксы надо хоть немного знать, так как на 90% VDS будет именно он.
В конце концов, это, например, не какая-нибудь платёжная система, где всё должно быть энтерпрайзно и секьюрно.
А зачем пользователям продуктов хостинги вообще? Если они пользователи, то подпускать к серверам их не стоит.
Да и все ли shared-хостинги настроены нормально? В их внутренности вы не сможете заглянуть. Вы уверены, что их админят знающие и адекватные люди? Приходится надеяться на неизвестных вам людей.
А в случае VDS можно хотя бы нанять кого-то на аудит.
Ну без знания азов администрирования UNIX нет смысла заниматься такой разработкой.
Для ознакомления вполне подойдёт убунта в качестве ОС. Программ в репе много, все идут с хорошими конфигами. Нода на vps в режиме «поиграться» поднимается парой команд.
Ну я не утверждал, что одно проще второго. Я просто указал на то, что примеры не эквивалентны и плохо сравнимы между собой. Собственно, как и пхп с нодой. У них есть свои области применения, в которых они хороши. И эти области на самом деле почти не пересекаются.
Это да, сейчас почти на любом языке можно 1-й командой поднять сервер даже с CGI. Но всё равно, способы выполнения кода разные.
В случае пхп наш сервер — внешнее приложение, исполняющее пхп-код и перенаправляющий STDOUT в тело ответа (ну в простом случае, который в статье).
В случае JS мы программно создаём сервер с неблокирующим IO, можем им управлять и т.д.
<?php
	echo 'Hello World!';
?>


const http = require('http');
const hostname = 'localhost';
const port = 8000;

http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello World\n');
}).listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});


Это как бы совсем разные вещи. Чтобы пхп-код отобразил hello world в браузере, нужно поднять и настроить сервер. А просто скормить этот код интерпретатору, то сообщение выведется в STDOUT. Так что аналогичный код на js — console.log('Hello world');.

А вот приведённый код на js запускает сервер, слушающий 8000-й и выводящий строку в ответ на запрос. Причём сервер асинхронный.

Даже упертые Node.js-разработчики должны использовать PHP для простых сайтов и приложений.

Ну прям обязаны.

К сожалению, такое могут себе позволить не все хостеры, поэтому и цены будут соответствующие.

2016 уже. VDS-ки дешёвые. Shared-хостинги уже отживают своё.

А вообще — очередная ненужная холиварная статья с субъективными мнениями.
Сейчас появилось много хороших редакторов (atom, sublime), так что в некоторых областях емакс с вимом уже проигрывают.
С другой стороны, у них есть свои ниши, в которых они будут ещё долго хороши.

Information

Rating
1,630-th
Works in
Registered
Activity

Specialization

Frontend Developer, Fullstack Developer
Senior
TypeScript
Angular
React
JavaScript
HTML
CSS