)))

и у него ушло на это меньше времени, чем изучать уже существующую

я не шучу

звучит как страшная история, коей она и является

Это респект, но лучше конкурентов посмотреть...

Чтоб идей понапи***

Ну так это же не sql

А в мире реляционок никакого профита от переезда от одной бд к другой нет.

Это респект, но лучше конкурентов посмотреть...

Я был в шоке с его скилла

просто с постгреса некдуа переезжать

А в мире реляционок никакого профита от переезда от одной бд к другой нет.

не надо холиваров

А в мире реляционок никакого профита от переезда от одной бд к другой нет.

Есть один - условия заказчика и его тараканы

просто с постгреса некдуа переезжать

Не, не люблю) имхо большая часть функционала не используется

Есть один - условия заказчика и его тараканы

если тебе надо переехать вместо какой нибудь mysql на базу данных, то тут тоже никакое орм не помжет

если тебе надо переехать вместо какой нибудь mysql на базу данных, то тут тоже никакое орм не помжет

Так всегда помогало

И бизнес логику писать прям средствами бд это не гуд

Это уже проходили, дорого и неудобно

Процедурами всм внутри бд)

Процедурами всм внутри бд)

удобно для того, кто шарит

но потом на проект приходит новичок

и ему становится очень и очень не по себе

И бизнес логику писать прям средствами бд это не гуд

Нормально все, я почти все делаю средствами бд

Если проект большой, то неудобно) особенно для enterprise

Нормально все, я почти все делаю средствами бд

Печаль)

Нормально все, я почти все делаю средствами бд

Страшные слова говорите, молодой человек

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

Нормально все, я почти все делаю средствами бд

Видимо ты один работаешь над проектом

Видимо ты один работаешь над проектом

я один остался :)

Вот вот

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

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

К примеру из sql и монго, тут никак без прослойки

я один остался :)

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

неуязвим, аки супермен

)))

ну до тех пор, пока начальство не решит переписать проект с нуля, используя труд джунов

Тут Вам конец и прийдет

К примеру из sql и монго, тут никак без прослойки

ну, сиквелом максимально всё посчитать, а в монгу писать чисто результаты

ну, сиквелом максимально всё посчитать, а в монгу писать чисто результаты

Я про связные данные

Да да и такое тоже есть)))

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

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

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

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

(это все без злобы, шуточки)

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

Бизнес логику надо описывать в микросервисе, а не в БД

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

Можно всё в хранимки запихать, и приложением их только дёргать. Будет шустренько)

(это все без злобы, шуточки)

шуточки, это когда вас просят сделать семь взаимноперпендикулярных красных линий зелёным и прозрачным цветом

вы ж про)

)))

шуточки, это когда вас просят сделать семь взаимноперпендикулярных красных линий зелёным и прозрачным цветом

Ну это из ряда организаций занимающихся оптимизацией и улучшением всего и вся

Можно всё в хранимки запихать, и приложением их только дёргать. Будет шустренько)

Я такой проект на дотнете видел, где из контроллера просто вызывалась хранимка к mssql и в ней происходило тупо все, начиная от валидации данных и заканчивая запихивания всего в разные таблицы

Я такой проект на дотнете видел, где из контроллера просто вызывалась хранимка к mssql и в ней происходило тупо все, начиная от валидации данных и заканчивая запихивания всего в разные таблицы

Ну если язык для хранимок нормальный, то почему нет. Про MSSQL ничего не знаю.

Валидацию, конечно, первичную надо на аппе делать)

Я такой проект на дотнете видел, где из контроллера просто вызывалась хранимка к mssql и в ней происходило тупо все, начиная от валидации данных и заканчивая запихивания всего в разные таблицы

это сложно поддерживать

версионность хранимок)))

Ну если язык для хранимок нормальный, то почему нет. Про MSSQL ничего не знаю.

Любая процедурная фигня на любом диалекте хранимок превращается в абсолютную лапшу

Подскажите пожалуйста что означает эта запись: str1 := oneRet().(string)

Подскажите пожалуйста что означает эта запись: str1 := oneRet().(string)

https://tour.golang.org/methods/15

Спасибо, не знал что так можно проверять тип переменной

это приведение

Спасибо, не знал что так можно проверять тип переменной

you had better rtfm & read docs

а можно как-то одновременно ожидать 2 канала? у меня два асинхронных события, оба из которых должны отработать прежде чем определённая горутина продолжит своё действие у меня есть подозрение что если реализовать вот так: go func() { // race condition! <- event1 <- event2 // will most likely dead-lock I guess fmt.Print("continue...") }() заблокирует намертво, ибо в случае race condition если первым обработает event2, а потом уже event1 то <- event2 заблокирует намертво

select?

а можно как-то одновременно ожидать 2 канала? у меня два асинхронных события, оба из которых должны отработать прежде чем определённая горутина продолжит своё действие у меня есть подозрение что если реализовать вот так: go func() { // race condition! <- event1 <- event2 // will most likely dead-lock I guess fmt.Print("continue...") }() заблокирует намертво, ибо в случае race condition если первым обработает event2, а потом уже event1 то <- event2 заблокирует намертво

select же

select?

так селект это "либо это либо это" а мне нужно обе одновременно ожидать

ERROR: S client not available

выражаясь в псевдокоде: if event1 == finished && event2 == finished

for { select … }

так селект это "либо это либо это" а мне нужно обе одновременно ожидать

select и счетчик

select и счетчик

хмм, это может сработать, но чёт как-то не чисто получится, ибо если один сигнал сработает 2 раза то тоже пройдёт

однако в именно моём случае исключено повторное срабатывание, но тем не менее

хмм, это может сработать, но чёт как-то не чисто получится, ибо если один сигнал сработает 2 раза то тоже пройдёт

select и битовя маска, чо )

select и битовя маска, чо )

разве чище ничего нет?

<- ..: mask |= (1 « 2) <-..: mask |= (1 « 3)

может и есть :)

https://play.golang.org/p/aJjUfzgqUc9 в любом случае да, deadlock

https://play.golang.org/p/aJjUfzgqUc9 в любом случае да, deadlock

https://play.golang.org/p/o7EQsR-mpOg - а так нет ?

https://play.golang.org/p/o7EQsR-mpOg - а так нет ?

хмм, не совсем понимаю конструкцию, т.е. канал буфер в 1 булеан.. но...

почему?

почему?

что именно - "почему" ?)

что именно - "почему" ?)

почему здесь он продолжает после <- secondEvent

типа буфер заполнен, поэтому ждать нечего?

типа буфер заполнен, поэтому ждать нечего?

тип того, у нас канал с ёмкостью в 1 элемент, отправили и идем далее

если так то да, вот это самое чистое и короткое решение

еще добавить wait group, и ты увидишь passed :)

еще добавить wait group, и ты увидишь passed :)

так Sleep же)

так Sleep же)

костыль

Ну так многое и запатентовано, или было когда-то...

Я не понял, если я буду юзать react, то могу попасть на иск? А как дела с ангуляром, вуе?

Я не понял, если я буду юзать react, то могу попасть на иск? А как дела с ангуляром, вуе?

Нет, это инструмент, вот если react подход с jsx утащить в что-то другое то можно и словить

костыль

ну это только для playground примера был sleep, ясное дело не в продакшн

Нет, это инструмент, вот если react подход с jsx утащить в что-то другое то можно и словить

Поподробней можно? К примеру я сваял на реакте сайт с jsx, и продал его, у меня будут проблемы, или это только как в качестве инструмента если продавать?

Поподробней можно? К примеру я сваял на реакте сайт с jsx, и продал его, у меня будут проблемы, или это только как в качестве инструмента если продавать?

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

А, понятно, спасибо.

https://play.golang.org/p/o7EQsR-mpOg - а так нет ?

ну вот вроде работает: https://play.golang.org/p/N5DlWv82dfO

ну вот вроде работает: https://play.golang.org/p/N5DlWv82dfO

Да, где-то так :)

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

Xeract))