Говорят, что если человек приобрел телескоп и использует его для наблюдений, то через некоторое время он обязательно захочет другой, получше. Так случилось и со мной. У меня есть телескоп PowerSeeker 127мм, но захотелось лучшего. По этой причине я даже было дело собрался точить свое зеркало, но позже обнаружил, что на AliExpress можно за недорого приобрести 200мм зеркало. Главное зеркало вместе с диагональным выходили где-то 6000 рублей с доставкой. Это очень дешево. На снимке выше, как раз такое зеркало, только что прибывшее по почте из Китая.

Купить-то купил, но это же не готовый телескоп. Нужна труба, держатель главного зеркала, диагонального, юстировки, фокусер. Как их изготовить самостоятельно? Решил, что по возможности буду печатать необходимые детали на 3D принтере. Но для этого их нужно еще спроектировать. Или найти дизайн в интернете.

Если поискать в интернете, то, конечно, «телескопы уже печатали». Вот примеры проектов:

1. Gaze Across the Solar System with a 3D-Printed, Raspberry Pi Telescope
2. Open Source DIY Telescope Prime Features Raspberry Pi and 3D Printed Parts

По разным причинам мне эти проекты не очень понравились. Я решил, что буду проектировать части телескопа сам. Чтобы жизнь медом не казалась я отчего-то решил, что буду делать проект во FreeCAD. До этого момента я уже делал кое-что в Компас 3D (я делал Marble-Machine). И теперь я подумал, что FreeCAD должен быть не сложнее…

В этой, третьей по счету, статье о создании GraphQL сервера с graphql-php я расскажу о том как бороться с проблемой N+1 запросов.

Не так давно я написал статью о том, как сделать свой GraphQL сервер на PHP с помощью библиотеки graphql-php и как с его помощью реализовать простое API для получения данных из MySQL.

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

В последнее время я все чаще и чаще слышу про GraphQL. И в интернете уже можно найти немало статей о том как сделать свой GraphQL сервер. Но почти во всех этих статьях в качестве бэкенда используется Node.js.

Я ничего не имею против Node.js и сам с удовольствием использую его, но все-таки большую часть проектов я делаю на PHP. К тому же хостинг с PHP и MySQL гораздо дешевле и доступнее чем хостинг с Node.js. Поэтому мне кажется не справедливым тот факт, что об использовании GraphQL на PHP в интернете практически нет ни слова.

В данной статье я хочу рассказать о том, как сделать свой GraphQL сервер на PHP с помощью библиотеки graphql-php и как с его помощью реализовать простое API для получения данных из MySQL.

Пока пара новых статей на технические темы еще в процессе написания, я решил опубликовать небольшой лингвистический материал. Достаточно часто замечаю, что коллеги, у которых английский язык — не родной, неправильно произносят некоторые характерные для IT сферы слова. И дело здесь не в том, насколько аутентично произносятся отдельные звуки, а именно в транскрипции. Регулярно встречал ситуации при общении с носителями, когда неправильно произносимое слово приводило к недопониманиям.

Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.

Задача

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

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9, 10-13
Продолжение. Каскадное удаление данных.

14. Другой пример: база данных интернет-магазина.

Вы познакомились, я надеюсь, с основными концепциями создания баз данных и теперь вы можете спроектировать простую реляционную базу данных. В примере ниже я резюмирую задачи, с которыми вы столкнетесь при разработке базы данных.
P.S. Информация ниже в очень упрощенной форме моделирует мыслительный процесс при создании базы данных.

Система интернет-магазина.

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

• Отображение товаров
• Классификация товаров
• Регистрация клиентов
• Добавление товаров в корзину покупок
• Отображение содержимого корзины покупок
• Оформление заказов посетителями
• И т.д.

Определяем сущности и отношения.

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

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9

10. Нормализация баз данных

Указания для правильного проектирования реляционных баз данных изложены в реляционной модели данных. Они собраны в 5 групп, которые называются нормальными формами. Первая нормальная форма представляет самый низкий уровень нормализации баз данных. Пятый уровень представляет высший уровень нормализации.

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

Продолжение.
Предыдущие части: 1-3, 4-6

7. Связь один-ко-многим.

Я уже показал вам как данные из разных таблиц могут быть связаны при помощи связи по внешнему ключу. Вы видели как заказы связываются с клиентами путем помещения customer_id в качестве внешнего ключа в таблице заказов.

Другой пример связи один-ко-многим – это связь, которая существует между матерью и ее детьми. Мать может иметь множество детей, но каждый ребенок может иметь только одну мать.

(Технически лучше говорить о женщине и ее детях вместо матери и ее детях потому, что, в контексте связи один-ко-многим, мать может иметь 0, 1 или множество потомков, но мать с 0 детей не может считаться матерью. Но давайте закроем на это глаза, хорошо?)

Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.


Схематическое представление связи один-ко-многим. Запись в таблице А имеет 0, 1 или множество ассоциированных ей записей в таблице B.

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

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

Как вы уже знаете из прошлых частей, данные хранятся в таблицах, которые содержат строки или по-другому записи. Ранее я приводил пример таблицы, содержащей информацию об уроках. Давайте снова на нее взглянем.



В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_id – первичный ключ таблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
В таблице клиентов ниже customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.

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

Другие части: 4-6, 7-9, 10-13, 14-15.

Руководство по проектированию баз данных.

1. Вступление.

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

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

И тут кто-то произносит слово «автотесты».

И сразу начинается: это целая история, это очень сложно, это очень дорого, от этого будет больше вреда, чем пользы и вообще это кровавый Enterprise и СЕЛЕНИУМ.

В этой статье я хочу немного поговорить об авторском праве и свободных лицензиях на ПО. Текст является результатом самостоятельного выбора лицензий и их применения к своим проектам.

Статья будет полезна тем, кто хочет:

— в общих чертах понять, что такое авторское право (но лучше обратиться к юристу);
— подобрать свободную лицензию для своего проекта;
— разобраться, что нужно писать в шапке файла исходного кода.

Данный мануал/гайд/etc написан для тех, кому лень собирать по кускам ту или иную информацию об установке «мака» на PC, все понятно и по полочкам.

На дворе 2017-ый год и довольно значительная часть сообщества PHP пытается использовать
PSR: PHP standard recommendation, цель которых — дать возможность заменять отдельные части фреймворков. Среди PSR-ов есть PSR-3, в котором описывается интерфейс для логгера. На данный момент существует множество совместимых с PSR-3 библиотек, в числе которых широко применяемый Monolog.

На тему PSR-3 и Yii 2.0 часто задают следующие вопросы:

1. Почему Yii 2.0 не совместим с PSR-3?
2. Как мне писать сообщения в совместимый с PSR-3 логгер?
3. Есть ли в планах сделать логгер Yii совместимым с PSR-3 и выпилить в отдельный пакет?

Разберём каждый подробно.

В UNIX системах есть одна очень древняя команда, которая называется dd. Она предназначена для того, чтобы что-то куда-то копировать побайтово. На первый взгляд — ничего выдающегося, но если рассмотреть все возможности этого универсального инструмента, то можно выполнять довольно сложные операции без привлечения дополнительного ПО, например: выполнять резервную копию MBR, создавать дампы данных с различных накопителей, зеркалировать носители информации, восстанавливать из резервной копии данные на носители и многое другое, а, при совмещении возможностей dd и поддержке криптографических алгоритмов ядра Linux, можно даже создавать зашифрованные файлы, содержащие в себе целую файловую систему.
Опять же, в заметке я опишу самые часто используемые примеры использования команды, которые очень облегчают работу в UNIX системах.

Хочу поделиться опытом разработки с использованием Xamarin (звучит как Замарин) на двух крупных проектах. Первый проект был под Windows Store и iOS, второй только под Андроид, но c использованием Xamarin.Forms. Xamarin быстро развивается, поэтому некоторые описываемые здесь моменты, могли уже стать неактуальными. Например: ещё летом мы переживали из-за дикого потребления памяти в Андроид и даже вручную вызывали сборщик мусора в некоторых местах, но в конце лета вышло обновление, которое закрыло многие наши проблемы с памятью.

В настоящее время на российском рынке представлено около 500 онлайн-игр, из которых более двух третей — браузерные. Некоторые из них приносят своим владельцам свыше миллиона долларов в месяц, другие, наоборот, только тянут деньги из кошелька своих создателей. И сегодня я расскажу вам, сколько конкретно стоит собственная разработка и выпуск на рынок браузерной онлайн-игры.

Каждая игра представляет собой бизнес-процесс, определённый рядом характеристик и параметров. На входе мы задаём средства, необходимые для разработки и продвижения проекта. На выходе имеем прибыль от его оперирования.


Рассмотрим по пунктам каждый элемент структуры затрат этого бизнес-процесса.

Добрый день, уважаемые Хабраюзеры!

Некоторое время назад, около месяца, на сервере нашей компании появился вирус. На одном из крупных проектов были поражены все *.js файлы. Ситуация обычная — в конец файлов был дописан вредоносный код. Яндекс выдавал предупреждение о заражении сайта и в техотдел пришло задание очистить его. Ситуация разрешилась достаточно быстро, проект был выгружен с чистого репозитория в продакшн, пароли сменили.

Однако вскоре со всех отделов компании в техотдел стали поступать жалобы о заражённых сайтах. Менеджерам жаловались клиенты, сеошники трубили что сайты теряют позиции. Началась настоящая эпидемия.

На днях вышла новая версия MODX Revolution — 2.1-pl и я решил отметить это дело написанием нового расширения.

Сначала хотел просто адаптировать для Revo свою старую разработку, для внутреннего сайта одной организации, но получилось, что переписал все заново.

Весь фронтэнд берет на себя замечательный плагин для jquery fullCalendar. У него есть только один недостаток — он не умеет работать с сервером. То есть, создавать/изменять события. Поэтому весь бэкэнд календаря пришлось написать самостоятельно на api MODX.