darksladen

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

Обработчики уровня actions в контроллерах - за содержание ошибки. К примеру, если у вас есть action MoveFile, который где-то там лезет во внешний сервис и пытается скачать файл и он падает по какой-то сугубо технической проблеме - таймаут у stream-а или еще что, то в конроллере имеет смысл этот Exception перехватить и завернуть во что-то более внятное:

public async Task<IActionResult> MoveFile()
{
    try {
        ...
    } catch (Exception exception) {
        throw new Exception("Moving file failed.", exception);
    }
}

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

Символьный SVG-спрайт. Подробное руководство
Как мы используем SVG-спрайты

Копай в сторону символьных свг спрайтов.

Я такие делаю.

Два варианта:

1. webgl, к примеру на threejs
   
2. пререндеры на канвасе
   

Оба варианта хороши.

Первый - мягким вращением.
Второй - вращение дискретное, но намного более качественная картинка, хорошая работа на мобильных устройствах, низкое потребление ОЗУ (не тупит в браузерах даже на слабых ПК).

Раньше делали на FLEX (flash), но сейчас эта технология вышла из моды.

https://css-tricks.com/svg-sprites-use-better-icon...

https://codepen.io/topicstarter/pen/gKbxEO вот это ромбики ....и стрелочки ...можно вообще всё там на svg сделать ...

тык

Вся работа с БД должна производиться в репозиториях.
Репозиторий работает с сущностями, так что, в случае использования active record ORM, из ar модели нужно будет создавать сущность и возвращать ее из репозитория. Не даем подключению к БД "гулять" по проекту. Entity это обычный popo в котором нет какой-либо логики, а есть лишь набор полей, геттеры, ну и методы для обновления состояния.

Например:

class EloquentUserRepository implements UserRepository
{
    public function findBySomething(string $something): ?UserEntity
    {
          $user = User::where('something', $something)->first();

          if ($user !== null) {
              return new UserEntity($user->id, $user->something);
          }

          return null;
    }
}

Может в строну доктрина копать?

Верное решение. Лучше откажитесь от eloquent и возьмите doctrine, если проект требует серьезной ORM.

Поиск: https://github.com/search/advanced
Коллекции: https://github.com/collections/

Laravel: https://github.com/goodnesskay/Laravel-Open-Source...

1.Firebug и CromeDevTools - смотрим расход ресурсов.
2. без кода ничего точно сказать не возможно.
3."как оптимизируют графику в 3d приложениях" - по разному. можно и на WebGL чистом написать)
4."поэтому сфера, конечно думаю слишком избыточны" - перепишите посмотрите в профайлере.
5. "Но не вижу эффективного способа и удобного способа для того, чтобы менять параметры только тех звезд, которые в поле зрения" - камера же куда то смотрит. нужно просто определить то что в камеру попадает, а что нет.

Предлагаю в качестве звёзд использовать не сферу, а спрайты. В свойствах материала выставить адитивное смешивание. У меня в сцене таким образом добавлено 15 000+ звёзд. Естественно, когда рисовал звёзды сферами (2 сегмента по широте, 4 по долготе), браузер съедал 700+ мб памяти, а когда были видны все звёзды, то улетали 1,5 Гб. Со спрайтами всё проще. Они сами ориентируются при пороте камеры и смотрятся естественно. Открывая такую сцену, браузер забирал 250-300мб и при нахождении в поле зрения всёх звёзд забирал не болен 700мб. Но мне видимость всех звезд и не нужна.

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

Кратко и понятно о JWT

После первого логина, клиенту возвращается сгенерированный сервером JWT. При каждом следующем запросе, клиент должен передавать JWT установленным API способом (например, через заголовок или как параметр запроса). Сервер декодирует header и payload и проверяет зарезервированные поля. Если все в порядке, по указанному в header алгоритму составляется подпись. Если полученная подпись совпадает с переданной, пользователя авторизуют.

В добавок к этому могу дополнить следующие шаги: мы удостоверились, что пользователь авторизован, и имеем на сервере payload (Это такой объект, в котором содержится все необходимые нам данные: userid и прочие. Формировали мы его тогда, когда генерировали наш JWT и отдавали его клиенту).
Далее делаем все, что душе угодно. К примеру, берем из payload userid пользователя, ищем его в БД, в ней уже смотрим права пользователя, и разрешаем или запрещаем какие-то действия.

Но есть одно но: если кто-то получит secret_key с сервера, считайте, что он получит доступ ко всем аккаунтам приложения.

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

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

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

Контейнеры существовали и до Docker. Докер, строго говоря, это всего лишь очень удобный набор инструментов, собранных воедино, для управления контейнерной виртуализацией. Но очень удобный.

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

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

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

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

Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

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

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

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

Нет. Только его и стоит.

Баги бывают разные. Если это ты накосячил, то само собой надо править безплатно, это ж твои косяки. Учись не косячить. Если давать гарантию на свои проекты полгода. то заказчик будет спокоен и доволен. Как показывает опыт, все баги вылезают в пределах первого месяца после начала эксплуатации. Полгода - это чистый маркетинг. Но иногда очень редко тоже пришлют какой баг. В убытках не будешь.
Если были двоякие толкования в ТЗ, то надо на будущее все заранее детально обсуждать и такие вещи исключать. Часто под видом бага заказчик пытается протащить изменение существующего функционала, в таких случаях помогает документация, где четко все описано. Тогда это доп. затраты на переделку.
По ценообразованию - в цену надо закладывать не только разработку, но и тестирование. Тогда все будет как надо.
По четким задачам, когда ясно что делать и сколько времени займет, можно давать прайс за всю задачу.
А когда "давайте сделаем что-нибудь", то почасовую оплату.
Вот как-то так.

Ребят, дайте несколько советов по работе с постоянными клиентами. Больше всего интересует политика оплаты услуг. Я, например, занимаюсь веб разработкой.. Как мне сделать такое ценообразование, чтобы и мне хорошо было и заказчика устраивало?

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

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

При старте проекта я всегда оговариваю период (обычно месяц) после его окончания, в течении которого я готов править любые баги связанные с моей работой бесплатно. Естестевнно все баги найденные во время разработки также правятся бесплатно. После прошедствии этого периода я либо беру фиксированную плату за каждую из задач, либо определенную сумму в месяц (обычно 20% от моего обычно заработка при фул тайм (примерно 100 часов в месяц для меня) занятости на проекте) за поддержания проекта в bug-free состоянии

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

Часто я использую следующую уловку. Перед стартом проекта клиенту говорю свою обычную почасовую ставку и чуть выше чем у меня есть сейчас. Говорю что у меня нет сейчас заказов и я готов поработать со скидкой (или другая причина), а потом когда заканчивается определенный этап работы можно сказать что появились более высокооплачиваемые для вас заказы и поэтому желательно продолжать без скидки, о которой вы упомянули заранее.