https://www.statlect.com/

Statlect

Statlect, the digital textbook | Probability, statistics, matrix algebra

Online book containing hundreds of lectures on probability, statistics and matrix algebra. Ideal for self-study.

Корисні поради і практики:

https://github.com/alexeymezenin/laravel-best-practices/blob/master/ukrainian.md

https://github.com/jupeter/clean-code-php

GitHub

laravel-best-practices/ukrainian.md at master · alexeymezenin/laravel-best-practices

Laravel best practices. Contribute to alexeymezenin/laravel-best-practices development by creating an account on GitHub.

#IT_guide • Читати

Telegraph

Zval (Zend value) - базова структура даних в PHP

zval виглядає так: typedef struct \_zval\_struct { zend\_uchar type; zvalue\_value value; zend\_uint refcount\_\_gc; zend\_uchar is\_ref\_\_gc; } zval; zend\_uchar type (тип змінної) зберігається як мітка, яка приймає одне з 8 значень, яке відповідає 8 типам даних в…

https://howhttps.works/ru/why-do-we-need-https/

howhttps.works

How HTTPS works

***🙀*** A cat explains how HTTPS works...in a comic! ***😻***

Про бабок

Общие принципы разработки хорошего кода, а именно про DRY, KISS, YAGNI и почему нельзя возвращать NULL. По-сути, первые 3 говорят говорят про очевидные вещи, но иногда разработчики про них забывают.

DRY— don't repeat yourself— нарушения принципа DRY называют WET — "Write Everything Twice" или "We enjoy typing"
— не допускай повторяющихся участков кода, на уровне функций, также не допускай классов с повторяющимся функционалом

```
KISS

```
— keep it simple, stupid или keep it short and simple— нет смысла реализовать дополнительный функционал, который возможно когда-нибудь пригодится
— бессмысленно делать реализацию сложной бизнес-логики, которая учитывает в себе все возможные варианты
— нет смысла подключать огромную библиотеку, если вам от нее нужна только пара функций
— нужно держать компоненты своей системы (классы, методы) в максимально простом, не осложнённом, не перегруженном состоянии
— перекликается с Single responsibility, Interface Segregation принципами из SOLID

```
YAGNI

```
— you aren't gonna need it— прежде чем писать новый компонент/функцию подумай: а нужен/на ли она тебе вообще? Может это можно не делать вообще? Или по крайней мере сделать это изящнее, проще, умнее, в рамках уже существующего/ей компонента/функции, не добавляя лишнего
— заказчик не должен оплачивать то, что он не заказывал
— бесплатных функций в продуктах не бывает
— ненужные новые функции могут впоследствии помешать добавить новые нужные
— новые функции должны быть отлажены, документированы и сопровождаться
— добавление новой функциональности может привести к желанию ещё более новой функциональности, приводя к эффекту "снежного кома"

почему нельзя возвращать NULL— накладывается неявное ограничение на код, который должен проверять значение на NULL
— обработка ошибок вручную

Мне нравится описание Filip Hanik всех этих принципов:
— Разбивайте задачи на подзадачи которые не должны по вашему мнению длиться более 4-12 часов написания кода
— Разбивайте задачу на множество более маленьких задач, каждая задача должна решаться одним или парой классов
— Сохраняйте ваши методы маленькими. Каждый метод должен состоять не более чем из 30-40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нём. Вы полюбите улучшать код.
— Придумайте решение задачи сначала, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться выше обозначенного правила. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код ещё и ещё и ещё… В счёт не идёт число строк, до тех пор пока вы считаете что можно ещё меньше/ещё лучше.
— Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения два очень важных момента. Если вы столкнулись с новыми требованиями, или не были оповещены о них ранее, тогда порой лучше придумать новое более изящное решение решающее и старые и новые задачи.

Прочла об одном забавном баге (хотя для разработчиков он не был забавным) — как-то в Израиле проходили испытания нового процессора для автопилота от фирмы Моторолла для истребителей (да, они делали не только телефоны) и все было хорошо, пока внезапно в полете происходит общий сброс процессора, автопилот выключается на полном ходу, пилоты переходят на ручное управление и сажают истребитель. Все ломают голову, прогоняют тест за тестом - на тестовом стенде все хорошо, в полете за пределами Израиля — все хорошо, на испытаниях в Израиле — опять та же проблема, что была. Наконец, проанализировав каждую строчку кода нашли в чем была проблема. В вычислениях автопилота использовался такой параметр как высота над уровнем моря. При этом разработчики логично предположили, что он не может быть в полете равен нулю или меньше нуля — автопилот же для самолета, а не подводной лодки. Но есть такое уникальное место на Земле и, находится оно в Израиле, где земля находится ниже уровня моря — это Мертвое море. Подлетая к нему переменная получала значение сначала 0, а потом и отрицательное. Уже при значении 0 происходило деление на ноль и программный сброс процессора.

#IT_guide • ЧитатьЗдесь я описала такие шаблоны GRASP, как Information Expert, Creator, Controller и Low Coupling и High Cohesion.
Буду только рада дискашену и/или потыканиям если что-то поняла не так??

Telegraph

GRASP — обобщенные рекомендации для проектирования систем

Information Expert информация должна обрабатываться там, где она содержится кто должен знать кол-во комментариев к посту? (comments to post) кто должен знать общее кол-во комментариев в блоге? (comments to blog) Необходимо определить, кто из участников системы…

SOLID
```
Single responsibility

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

Пускай у вас есть какой-то класс Date, который отдает информацию о температуре и времени. Если какой-то Вася хочет получить информацию о времени, ему придется продублировать оба метода этого класса. То же касается и какого-то Андрея, который захочет получить информацию о температуре.
————— ————— —————
|DateTemp| копия |Date | копия |DateTime |—————— <——— ————— ———> ——————
|- temp() | |- time() | |- time() |
—————— |- temp() | ——————
—————
Правильнее будет создать 2 отдельных класса, которые будут возвращать температуру и время соответственно.

```
Opened-closed

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

```
Liskov Substitution

```
— поведение наследующих классов не должно противоречить работе базовых
— подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый
— там где используется Child класс, должен подходить и его Parent

К примеру, у вас есть классы Child и Parent. Неправильной будет следующая реализация:
— используя Parent можно вызвать любой метод, а используя Child нужны дополнительные действия для вызова того же метода. Например, вызов какого-нибудь init()
— если метод getMessages() класса Parent возвращает коллекцию из базы данных, Child не должен возвращать пустой массив или null

Допустим, у вас есть классы Rectangle и Square, который наследуется от первого. В случае, если написать тест на Rectangle, который будет считать площадь функцией ab, возникнет ошибка, т.к. в дочерном классе Square не реализована сторона b.
——— ————
|Rect | extends | Square* |
——— <———— ————
|- a() | |- a() |
|- b() | ————
———

Interface Segregation— много интерфейсов предназначенных для клиента лучше, чем один общий
— клиенты не должны зависеть от методов интерфейса, которые они не используют
— интерфейс является принадлежностью не сервера, и клиента— при изменении одного метода интерфейса будут перекомпилироваться остальные классы, которые имплементятся от этого интерфейса, но которые этот метод даже не используют

#IT_guide • Читатище 10 трюків з Eloquent

Telegraph

ще 10 трюків

11. Сортування по геттеру Взяти до прикладу стандартний і часто використовуваний геттер function getFullNameAttribute() { return $this->attributes['first\_name'] . ' ' . $this->attributes['last\_name']; } Вам потрібно відсортувати записи по полю full\_name?…