Нужно ли программисту уметь считать?

Можно спрогнозировать модель на основании статистических данных. Тут ошибку можно уместить в 5-10%. Но там учитывать нужно множество факторов. Поэтому если говорить о корректности вопроса - он некорректен.

Однако подход к прогнозированию правильный. Но тут достаточно взять любой график в декартовой системе и спросить как ведет себя функция.)

Нужно ли программисту уметь считать?

Решение- идем в Гугл, пишем вопрос, в Питере 2492 аптеки. Зачем заниматься мыслеэксперементами если все давно посчитано.

А Вашим методом вы промахнулись почти на треть. А это очень много. Таким образом можно усложнить и посчитать количество аптек в Ленобласти или по всей России, вы там даже порядком ошибиться можете.

Задача «Получить значение у N url из списка» с собеседования на Go

Вот тут ошибка будет, получается запрос N раз одного и того же адреса (go <= 1.23)

for _, url := range urls {
semaphore <- struct{}{}
wg.Add(1)
go func(u string) {}(url)
}

Если же делать параллельную обработку в несколько потоков в пуле, то правильнее все-таки делать вот так

const poolSize = 3
type ResultData struct {
	BodyLen int64
	Err error
}

addressCh := make(chan string, 3)
resultCh := make(chan ResultData, 3)

wg := &sync.WaitGroup{}
wg.Add(poolSize)
for c := 0; c <= poolSize; c++ {
	go func() {
		for address := range addressCh {
			body, err := doRequest(address)
			resultCh <- ResultData{BodyLen: len(body), Err: err}
		}
		wg.Done()
	}()
}

go func() {
	urls := []string{"1","2","3"}
	for _, url := range urls {
		addressCh <- url
	}
	close(addressCh)
}()

type Result struct {
	AllLen int64
	Errors []error
}

result := Result{
	AllLen: 0,
	Errors: make([]error, 0),
}

go func() {
	for reqRes := range resultCh {
		if reqRes.Err != nil {
			result.Errors = append(result.Errors, reqRes.Err)
		} else {
			result.AllLen += reqRes.BodyLen
		}
	}
}()

wg.Wait()
close(resultCh)

fmt.Println(result)</code></pre><p><br> Все остальное от лукавого</p>

Государство и Т-киллеры

Вы на выборах давно были? =)))
У нас в рамках 4 и 6 лет можно сделать неверное решение и молчать теже 4 — 6 лет=)))

Государство и Т-киллеры

Вообще народом, и мной в частности, как части этого народа.
Если брать Россию, то читаем внимательно основной документ

1. Носителем суверенитета и единственным источником власти в Российской Федерации является ее многонациональный народ.
2. Народ осуществляет свою власть непосредственно, а также через органы государственной власти и органы местного самоуправления.
3. Высшим непосредственным выражением власти народа являются референдум и свободные выборы.
4. Никто не может присваивать власть в Российской Федерации. Захват власти или присвоение властных полномочий преследуются по федеральному закону.
Источник: constitutionrf.ru/rzd-1/gl-1/st-3-krf

Вы наверно должны были слышать о таком механизме — «Выборы» называется, в котором люди выбирают управленцев которые должны будут отвечать за разные вещи такие как образование, медицина дороги и прочее. Это как бы так должно работать в целом.
Ключевое слово ОТВЕЧАТЬ =)) Не властвовать, не управлять, а отвечать)

И как у любого гражданина у меня есть полное право спрашивать у кого угодно, вплоть до президента — куда зачем и почему (право конечно есть, но ответят вряд ли, если в России, такой уж строй у нас). Функция выбранных людей, учитывать мнение большинства не «обижая» меньшинство.

И если читать будете внимательнее, я не зря указал 10 условных человек. Делегирует полномочия группа людей, жители города Москвы, жители Центрального Округа, жители Нью-Йорка и т.д. Каждый по своему «условному проценту».

Государство и Т-киллеры

Если мы будем рассматривать демократический строй. (Не псевдо-демократию, не толитаризм и не прочие схемы устройства, которые кстати возникли изначально из демократии).
То проведём аналогию. Было 10 человек которые собрались на шашлыки, но у всех до дня Х было куча работы, тогда они посовещались и позвали условного Петю со стороны и сказали ему «Петь, у нас тут своих дел невпроворот, давай мы тебе 5000 руб. а ты сгоняй в магазин за мясом, шампурами и углём». Т.е. они группой передали заботу о мясе и прочем этому Пете.
Вот и весь сказ про государство, аналогия надеюсь ясна.
Государство есть некий менеджерский состав со стороны которому делегировали полномочия по обороне границ, поддержанию порядка и прочее. И в любой демократической стране, если люди группой недовольны менеджером, они его увольняют (идут и требуют отставки) и в 90% случаев их требование удовлетворяют, а не из водяных пушек расстреливают.

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

В общем доля истины тут есть, но только доля.

Функциональная СУБД

Ну, во-первых я бы для этого использовал графовую БД.
И в принципе в РСУБД вы этот код так же можете завернуть в функции и будет читаться так же.
Я имел ввиду алгоритмическую сложность достать данные с диска.

Функциональная СУБД

А смысл? Тот же SQL что и был, только скобочек добавилось, сложность выборки, как была так и осталась. Написание каким было таким и осталось. Оборачивать выборку как раньше было нужно так и до сих пор нужно.

От выдачи кредитов к бэкенду: как изменить свою карьеру в 28 лет и переехать в Питер, не меняя работодателя

Какая длинная рекламная статья =)

Один из сотни способов публикации нескольких production проектов на одном сервере

severalnines.com/blog/how-deploy-postgresql-high-availability

Базы можно расположить в docker, но есть нюанс, если грохнуть все контейнеры, или грохнуть до окончания синхронизации, то все данные упадут вместе с контейнером.
Так что как вариант — проброс данных в хостовую систему. Для кворума лучше использовать 3 сервера с базами. Чтобы если грохнулась одна, оставалось ещё две и если грохнется ещё одна база до восстановления первой, приложение жило.

Один из сотни способов публикации нескольких production проектов на одном сервере

Потому что nginx работает как reverse proxy, и отправлять его на ip адреса внутренней сети докера грешно. Во-первых могут быть разные подсетки. Во вторых после ребута или ребилда докер контейнер может сменить IP адрес docker сети и вы получите нерабочий хост. Придётся лезть в nginx править конфиг.
Поэтому и линкуют контейнеры через имена, потому что IP может быть любым и в теории может сменится, так как там свой аналог dhcp

Один из сотни способов публикации нескольких production проектов на одном сервере

Я бы сказал что это не очень хорошее решение.
Есть три более правильных подхода
1) Minikube со всеми вытекающими
2) Поставить на хостовую машину nginx и использовать его как proxy, сертификаты для SSL можно хранить в нём же. Достаточно поднять пул контейнеров для каждого приложения на разных портах и проксировать запросы на них. (Чтобы доступа извне не было достаточно написать 127.0.0.1:%port%:80)
3) Если и использовать nginx в контейнере, тогда использовать docker external network и разделить приложения по подсетям докера (очень геморойный путь, проще использовать пункт 2)

Про ИТ-бизнес и не только

Возвращаясь в уютный мир ИТ офисов и сложных информационных систем, аналог технолога здесь — это ИТ архитектор. Он может не быть програмистом/админом/… (скорее даже «не должен быть», хотя технический бекграунд и желателен), но именно он занимается превращением набора хотелок в архитектуру («технологическую карту»), которую в дальнейшем програмисты («токари») превращают в конечный продукт («изделие»)

Вы, простите, с дуба рухнули? Как возможно спроектировать то, о чем ты не знаешь, у Solution Architect или ИТ архитектора должен быть очень большой бэкграунд, знание нескольких технологий структур на них, опыт их эксплуатации от и до. Собственно разработкой и как надо управляет архитектор, а сроками материальным обеспечением и т.д. менеджерские позиции (это если по фэн-шую).

И инженеров-технологов отправляют на стажировки на производства токарями, слесарями и т.д. (ну по-крайней мере отправляли, что сейчас я чёрт знает).

Так что не несите ерунды.
Архитектор это очень сильный и скилловый разработчик с + опытом в администрировании, эксплуатации, сбору аналитики и управлению командой.

Не переусложняйте ваш CI/CD и пользуйтесь Docker'ом осмысленно

Нет, процесс как раз один и тот же, результат в tar.

Зачем? какая версия для интерпретируемых языков? Какая виртуальная машина для Java и C# где вся эта информация будет храниться? Как легко и просто всё это установить?

Чтобы можно было потом запустить его либо на чистой системе, либо промежуточным этапом собрать докер образ с нужным окружением и запихнуть туда tar

Тот же самый вопрос, какие зависимости? Библиотеки? Конфиги? Куда всю эту инфу нужно класть?

БД это тоже серверное приложение, однако, позвольте спросить, она только в докере распространяется?
Postgresql можно запустить на чистом метале или… упаковать в докер образ

Можно конечно, но зачем? У вас нет полной изоляции от системы, образ окружения может пользоваться всеми вычислительными способностями машины, конфиги можно пробросить. И Postgres поставляется в пакете deb или rpm на машины, или собирается также через makefile с установкой всего куда нужно. Опять же, makefile по сути тот же Dockerfile или Vagrant file. Что мешает собирать 3-4-5-25 вариантов и в докер и в deb и в tar сорцы запихивать.

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

Не переусложняйте ваш CI/CD и пользуйтесь Docker'ом осмысленно

Эм, какой-то бред…
В зависимости от приложения выбираешь метод распространения.
Хочется разделить CI и CD кидайте хук по завершению CI зачем куда-то в архив писать?

Серверные приложения намного удобнее распространять через docker или vagrant или другие способы изоляции (как раз сохранение окружения). И всегда всё будет работать именно так как должно.
Сборки десктопа или т.д. так же вешаем два или более паплайнов и собираем хоть rpm хоть deb хоть msi, хоть всё вместе разом. И мы точно знаем какие там зависимости, и что это будет работать.
Приложение не отделимо от окружения, а окружение от работоспособности софта, скидывать бинарник который чёрт знает от чего зависит, или сорцы которые чёрт знает как собирать, просто быть самому себе злым буратино.

Опрос. Новый тег <?~ $value ?> для HTML-экранирования данных в PHP

Если пользовательский интерфейс содержит настройки типа фильтров, сортировки, галочки «показывать итоги» и т. п., то всё это тащить в модель или контроллер и на каждый чих их дёргать? — а как вы ещё собираетесь это делать? Вы в любом случае будете дёргать бэкенд, или же как раз переходим к модели MVVM где вьюха решает что где как и в каких количествах (если это десктоп предположим). в вебе передавать все результаты, страннова-то, особенно если данных много.

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

Экранировать нужно всё по умолчанию, выводить сырые данные в каком-то контексте только при стопроцентной уверенности, что это данные уже готовы для этого контекста. Это требование безопасности. — ключевое слово выводить. Вот то что выводите и экранируйте на этапе прекомпиляции представления. А индексы, и прочее не вижу смысла экранировать если они не выводятся, если они числовые. Расскажите мне как не экранированное число в выводе может навредить? Или как если у вас на этапе валидации проверяется имя, которое состоит только из букв (в России по крайней мере), внезапно начнёт содержать html текст который вы не вводили?

Видимо, да, про разные. Не похоже, что вы говорите о разделении ответственности подобному MVC. — Да нормально разделяется ответственность. Группировки, сортировки, фильтры, делаются на уровне сервиса. А как выводить ( слева, справа, в столбик, таблицей или гридом ) решает представление. При изменении данных, представление сообщает это контроллеру, который в зависимости от того что изменилось дёргает тот или иной сервис, модель, метод. Я же вам не говорю, что вы должны представление готовить на уровне модели. Я говорю вам прямым текстом.

Модель -> Препроцессор -> Представление.
В препроцессоре дёргается библиотека которая приводит данные на вывод в нужный формат который использует представление.

Опрос. Новый тег <?~ $value ?> для HTML-экранирования данных в PHP

Передать в представление массив из элементов списка — это мусорить? — нет, а вот проходить по массиву и делать с ним манипуляции не касающиеся вывода. ( складывать, вычитать, умножать, проверять на вхождения и прочее. )

1. Геттеры и сеттеры часто являются оверинжеренингом
2. Не путайте инкапсуляцию с сокрытием. То, что мы перенесли какую-то переменную, связанную с объектом, в его свойство уже является инкапсуляцией. — Мы ищем решение проблемы или что? Вам нужны данные которые вы ожидаете. Используйте get и set чтобы отдавать и получать те данные которые вы ожидаете. Не просто так же придумано.

Нарушение границ ответственности, только вьюха должна решать в какой форме выдавать данные. Банальное прибавление 1 к индексу массива, чтобы получить номер элемента — это чисто функция представления.
— Мы с вами об одном и том же говорим? Отображайте данные как хотите. Данная абстракция относится скорее в препроцесу представления, чем к логике модели, вы заранее приводите данные для отдачи клиенту (HTML, URL и прочее к виду который нужен htmlspecialchars и т.д. а далее навешивайте всё как хотите).

А если мы заэкранируем индекс, а потом прибавим заэкраннированную 1 то получим, мягко говоря, не совсем то, что ожидаем. — А зачем вам экранировать int float double вы не знаете что где используете в вашем приложении? Экранируйте на этапе передачи то что нужно, зачем экранировать и преобразовывать всё?

Мы с вами видимо про разные вещи разговариваем.

Опрос. Новый тег <?~ $value ?> для HTML-экранирования данных в PHP

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

Итого посчитать? Это задача бизнес логики, а никак не представления, или если у вас в 3-ёх представлениях «ИТОГО» нужно, а в 4-ом нет, вы будете считать отдельно в каждом из трёх?

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

Группируйте сколько угодно, опять же какая разница группировать подготовленные данные или неподготовленные к выводу?
А как это делать, уже вопрос задачи.

Теперь по факту:
Вы хотите узнать нужен ли оператор, я вам говорю, что по моему мнению не нужен, так как 99.9% проблем с обработкой вывода я могу решить так или иначе без его использования (и намного гибче), на каком либо уровне абстракции, там где мне это нужно.Лишняя фича просто.

Вплоть до того что объект можно декорировать как угодно, для JSON, для XML, для HTML, да хоть для слепых в аудио виде выводить.

Опрос. Новый тег <?~ $value ?> для HTML-экранирования данных в PHP

— экранированные значения метода __to_string объектов ( вот это я впринципе не использую и ни разу не видел чтобы где-то использовалось, по мне, так плохой тон пытаться объект неявно приводить к строке ИМХО).

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

— экранированные значения публичных свойств объектов ( для этого существуют геттеры и сеттеры, инкапсуляция наше всё )

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

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

Представляете такую абстракцию, готовящую данные для представления заранее, а не декорированием по месту использования? (Да, фильтры, не вижу ничего страшного чтобы ввести ещё один уровень для подготовки данных)

Опрос. Новый тег <?~ $value ?> для HTML-экранирования данных в PHP

Декоратор?)

Есть некий абстрактный сервис преобразования ( будем использовать немного магии ).

```php
interface IDataPreparator{

public function setData( array $data );

/**
* return array
*/
public function getData();

}
```

Массив передаём предположим так.

```php

$data = [
'dateOne' => ['value' => '10 feb 2012', 'type' => 'date', 'format' => 'RU' ],
'dateTwo' => [ 'value' => '10 feb 2012', 'type' => 'date', 'format' => 'EN' ],
'HtmlString' => ['value' => 'Hello world', 'type' => 'html', 'options' => ['encoding' => 'utf-8']]
];

```
Где ключ название переменной, а значения правила.

Да, придётся много писать, но более универсальное средство.
Да и делается это сколько угодно раз.
Чтобы вернуть всё в состояние переменных сделаем extract();

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

```php

class Controller {

public function actionIndex(){
$data = Model::getData();
$preparedData = (new DataPreparator()) -> setData([ 'dateOne' => ['value' => $data['dateNewYork'], 'format' => 'EN' ] ])->getPreparedData();
$this->renderView('view', $preparedData );
}

}

```