Друзья, вновь пришло время авторской колонки корпоративного блога PG Day’17. Предлагаем вашему вниманию сравнительный анализ работы с PostgreSQL из популярных ORM от varanio.

ORM (Object-Relational Mapping), по идее, должен избавить нас от написания SQL запросов и, в идеале, вообще абстрагировать от базы данных (от способа хранения данных), чтобы мы могли работать с классами, в той или иной степени выражающими объекты бизнес-логики, не задаваясь вопросом, в каких таблицах всё это по факту лежит.

Посмотрим, насколько это удается современным библиотекам на PHP. Давайте рассмотрим несколько типичных кейсов и сравним ORM с голым SQL, написанным вручную.

Введение

Этот туториал я пишу прежде всего для себя, для того чтобы иметь возможность быстро на основе начального шаблона ASP.NET Core приложения создать минимальное приложение с поддержкой npm, Webpack и TypeScript (у которого будет работать отладка из Visual Studio).

В своей статье я хочу поделиться с вами опытом использования нового Angular как основы для наших enterprise приложений. Речи о том, что новый Angular лучше, чем React, Vue или какая-то другая популярная сейчас библиотека, в статье не пойдет, хотя, конечно, я буду сравнивать его с конкурентами. Все решения имеют свои плюсы и минусы, и то, что хорошо подошло одному проекту, может устроить сущий ад в другом. Итак, прежде чем объяснить, чем нас зацепил новый Аngular, расскажу немного о том, что мы уже используем в разработке.

Наш основной проект имеет долгий путь развития и построен на уже устаревших технологиях — Marionette + Backbone + Coffescript. Пару лет назад мы поняли, что развивать проект в таком стеке стало довольно тяжело, и начали изучать альтернативы в экосистеме фронтенда и думать, как же нам мигрировать туда нашего «зверя».

Заинтересовавшись вопросом скорости работы операций упаковки и распаковки в .NET решил опубликовать свои небольшие и крайне субъективные наблюдения и измерения по этой теме.

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

Всем привет! Недавно Дэн Абрамов, создатель Redux, оставил довольно массивный комментарий к статье на Medium Things nobody will tell you about React.js, который очень быстро разошёлся популярностью и довольно скоро набрал раза в 3 больше рекомендаций, чем сама статья :)
Собственно, текущая статья является моим переводом его комментария, так как последняя содержит ценные замечания по поводу актуального и будущего состояния React / React Router.
Надеюсь, кому-то это будет полезным.

Привет, спасибо за обратную связь! :)

Я ценю, что вы поделились своим неприятным опытом работы с React.

Ваш пост содержит широко распространенные в React сообществе заблуждения, поэтому мне захотелось воспользоваться моментом и разъяснить их для любого, у кого имеются те же проблемы.

Это вовсе не означает, что React для всех работает одинаково хорошо, или что затронутые вами проблемы неактуальны. Но есть несколько моментов, которые, на мой взгляд, важно обозначить для правильного понимания этих проблем.

Предисловие

• Общее направление развития .NET и ошибки Microsoft;
• Чего ждать от .NET Core в ближайшем будущем;
• Стоит ли мигрировать на .NET Core, если у вас легаси на .NET Framework;
• Проблемы и победы .NET на поприще кроссплатформенности;
• Java vs .NET на рынке enterprise решений;
• Чем хороши tuples и pattern matching в С# 7, а что стоило сделать иначе;
• Небольшие, но приятные фичи C# 7;
• Деградация сообщества разработчиков (и есть ли она);
• Правильный подход к диагностике багов и постановке правильных вопросов на SO;
• Гайд по изучению новых языков и платформ;
• Проблемы с базовыми типами: числа, текст, дата и время;

Что ж, всё плохо. Немного забавно так говорить: на конференции (Web à Québec) было много разговоров об удивительном будущем и вещах, возможных благодаря новым технологиям. О новых средствах и устройствах, которые должны сделать нашу жизнь проще. Мои знакомые знают, что у меня обычно очень циничный взгляд на технологии; лично я боюсь всех этих умных устройств, которые реагируют на мои слова, чем восхищались другие спикеры.

В основном потому, что чем больше времени я трачу на программирование и провожу в этой отрасли, тем больше узнаю, как всё работает изнутри, и тем меньше доверия всё это мне внушает. Я подобрал изображение для слайда. Это картина «Триумф смерти» Питера Брейгеля. В некоторой степени она раскрывает моё отношение к «умному дому».

Перейти в канал YouTube!

Вашему вниманию предлагаю перевод статьи Sacha Greif "Что же такое этот GraphQL?"

Если вы такой же, как и я, вы обычно проходите через три этапа, когда узнаёте о новой технологии:

• Отрицание: Ещё одна JavaScript библиотека?! Зачем? У меня уже есть jQuery!
• Интерес: Хм, наверное мне следует взглянуть на эту библиотеку...
• Паника: Помогите! Мне нужно изучить эту библиотеку прямо сейчас, иначе мои знания устареют!

Есть одна хитрость для поддержания благоразумия в эпоху быстроразвивающихся технологий: изучать новые вещи между вторым и третьим этапом, как только интерес задет, но пока технология ещё не распространена повсеместно.

Именно поэтому сейчас самое время узнать, что же такое этот GraphQL, о котором вы повсюду слышите.

В интернете кто–то неправ

Случайно выяснил, что существует непонимание того, что такое АБ–тест и как его проводить. Поэтому небольшая статья с базовыми принципами и примерами как делать не надо может быть полезна. Советы рассчитаны на читателя только начинающего знакомство с АБ–тестами и проект с небольшой аудиторией. Если у вас большая аудитория, то вы и так знаете как проводить тесты.

Мой опыт проведения АБ–тестов связан с мобильными приложениями, поэтому какая–то специфика может прорваться несмотря на намерения писать только о базовых вещах.

Определение

АБ–тест — это способ понять стал ли ваш продукт лучше при изменении его части. Скажем, у вас есть гипотеза, что какое–то изменение увеличит ключевую метрику продукта больше чем на 10%. Вы берёте новых пользователей и одной половине даёте контрольный вариант продукта, а другой — с реализованной гипотезой. Дожидаетесь пока разница между значениями метрики станет статистически достоверна, то есть не изменится при продолжении теста с вероятностью 90–95%. Как только результаты достоверны — оставляем победителя и запускаем следующий тест.

Сейчас service worker — это программируемое прокси внутри браузера

Трансдьюсеры были анонсированы еще в далеком 2014, с тех пор по ним было написано немалое количество статей (раз, два), но ни после одной статьи я не мог сказать, что понимаю трансдьюсеры кристально ясно. После каждой статьи у меня возникало ощущение, что я приблизительно понимаю что-то сложное, но оно все равно оставалось сложным. А потом однажды в голове что-то щелкнуло: "я ведь уже видел этот паттерн, только он назывался иначе!"

Пару недель назад, я решил взять простейший пример HTTP сервера на Go и измерить его производительность. Потом я смело взял Phoenix, прогнал на тех же тестах, и расстроился. Результаты были не в пользу Elixir/Erlang (45133 RPS у Go и всего 3065 RPS у Phoenix). Но Phoenix — это тяжело. Надо что-то хотя бы примерно равное по простоте и логике разработки тому, что есть на Go: когда есть путь — "/" и handler для него. Логичной аналогией мне показалось решение cowboy + plug, где у нас есть Router, который так же ловит "/" и отвечает на него. Результаты убили — Elixir/Erlang опять оказался медленнее:

Golang
sea@sea:~/go$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  452793 requests in 10.03s, 58.30MB read
Requests/sec:  45133.28
Transfer/sec:      5.81MB

elixir cowboy plug
sea@sea:~/http_test$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
  184703 requests in 10.02s, 28.57MB read
Requests/sec:  18441.79
Transfer/sec:      2.85MB

Как жить дальше? Две недели я не спал и не ел (почти). Все, во что я верил все эти годы: совершенство vm erlang, ФП, зеленые процессы, было растоптано разорвано, сожжено и пущено по ветру. Немного отойдя от шока, успокоившись, и подтерев сопли я решил разобаться, в чем дело.

В течение полугода я программировал преимущественно на Go. И я разочарован. По двум причинам:

• В Go особенно трудно придерживаться функциональной парадигмы. По сути, язык препятствует функциональному программированию. Меня это разочаровало, потому что в императивном коде, который я пишу, большое количество шаблонных кусков. К тому же, как мне кажется, в этом случае выше риск ошибок, в отличие от использования функциональных абстракций.
• Я считаю, что Go упускает свои шансы. В программных языках появились замечательные нововведения (особенно в сфере проверки и вывода типов — type inference), делающие код безопаснее, быстрее и чище. Мне хотелось бы, чтобы Google использовала своё влияние, чтобы поддержать некоторые из этих идей.

Я не первый, кто воспринимает Go подобным образом. Вот публикации других людей, разделяющих мои впечатления:

• Why Go Is Not Good
• Everyday hassles in Go
• Three Months of Go (from a Haskeller’s perspective)
• The Language I Wish Go Was

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