всё уже сказано

Обязательно надо! И тут два варианта: или тебе объяснят что-то недопонятое, или, может быть, и правда ничего идеального в мире не существует и надо уметь правиьно выбирать инструменты...

http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/

Слава, я читал. И, кажется, твой перевод был на хабре? Как-то не вполне сторго и убедительно.

нет, не мой =)

Тут вот вчера запостили: https://github.com/Konstantin8105/Effective_Go_RU

Переводчику, конечно, респект, но редактура нужна явно! Не такой хороший текст получился, как в оригинале

Необходимость перевода технической литературы вообще весьма сомнительна.

И вобще, с языком как-то чем даьше, тем больше косноязычия. Самый печальный вариант - публичные выступления на наших конференциях. Люди не только говорить не умеют, но даже, зная, что придется лезть перед камеру/микрофон, даже и учиться не хотят :(

Необходимость перевода технической литературы вообще весьма сомнительна.

ну можно попереводить для совершенствования в языке + подучить сам материал книги ну и как бы показываешь, что чтение тех литературы присутствует :)

ну хоть что-то говорят - это уже здорово, всё приходит с опытом

Да и пока сам переводишь, хоть поймешь, наконец, что там написано=то хотя бы :)

в общем переводить полезно, читать чужой перевод сомнительно

Слава, надо как-то все равно на это внимание обращать. Если выступающий сподобился выступить, то пусть хотя бы нескоько вещей учтет:

Необходимость перевода технической литературы вообще весьма сомнительна.

я бы сказал что вообще отсутсвует

1. Надо иметь что сказать. 2. Надо заранее снать план выступления, какие темы будут, в каком объеме, а каких не будет. 3. Заранее продумать, как ты преподнесешь то, о чем речь таки будет. 4. Научи ться слышать свое следующее слово до того, как ты его скажешь. Если следующее слово - это междометие "как бы" и ему подобные - лучше просто его не сказать, а набычась поглядеть в зал четверть секунды 5. Научиться не сидеть на шее у зала. Все вопросы типа "а кто знает, в какой версии ядра Linux появились CGroup" - это просто до свидания. Вышел выступать - выступай, а не еби людям моск

Ну, и куча других косяков... Все приходит с опытом. Жаль, что не у всех такого опыта пубичных выступлений достаточно

москва не сразу строилась =) надо же и интернам практиковаться на ком-то

Ну, пипл хавает пока что, так что никаких проблем. :) И есть прекрасные ораторы, не побоюсь этого слова. :) Это, в первую очередь те, кому есть таки что сказать, у кого глаза горят это донести. А полно и такого убожетва - мама не горюй. Хоть и специалист, вроде, и дело знает... Его что туда пистолетом загоняли выступать, блин???

Я это не про конференции Go, а вобще. Те же курсы лекций от Mail.RU или Яндекса. Бывает слушаешь минут 15-20 для начала что-то и просто физически страдаешь, как человеку плохо, так не надо было и лезть в это! А бывают просто суперские лекторы! Но сильно реже :(

вообще-то, все 5 пунктов - чистое капитанство

Да!

то есть, если человек не умеет этого - не надо бы ему - пока? - выступать

другое дело, что как этому научиться, не выступая?

Почитаешь курсы по UNIX по две пары до обеда и две после хотя бы пару недель, еще и не так задембелюешь :)

наших западных коллег этому учат прямо в школе

а кого не в школе - того в универе

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

ну вот у нас нет специально риторики ни в школе, ни в вузе.

И к лекциям готовился, особенно поначалу! Но то, что я вижу на ютюбе - это просто модой об забор, даже если то под вывеской Яндекса или MRU идет

то есть, ежели кто из наших это умеет - это просто талант, а талантов мало, как известно

Талант талантом, но если нет элеметарных речевых навыков - лучше, наверное, не надо. Хотя опять же, кто хочет выступить и есть о чем - почему нет? Если хочешь, то обычно и можешь, а опыт - дело наживное.

это от отношения к аудитории зависит - имхо достаточно прогнать раз перед зеркалом (дабы посмотреть как это выглядит со стороны)

если криво выглядит, то повторять пока не понравится, простой же алгоритм

А потом достаточно посмотреть запись на ютюбе и просто умолять их удалить это унылое гавно :(

Талант талантом, но если нет элеметарных речевых навыков - лучше, наверное, не надо. Хотя опять же, кто хочет выступить и есть о чем - почему нет? Если хочешь, то обычно и можешь, а опыт - дело наживное.

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

но, повторюсь, это редкость

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

если криво выглядит, то повторять пока не понравится, простой же алгоритм

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

И свои выступления - тоже! Обычно когда свои - то ты и есть самый строгий зритель :)

это подразумевается (что глядя в зеркало ты сравниваешь себя с хорошими выступлениями)

Мы тут не о конкурсе мужской красоты еще? Я про косноязычие на наших конпутерных конференциях и курсах тут разоряюсь. Хотя, я может быть, что-то пропустил?

А вообще , что посоветует, я б научился вытупать

А вообще , что посоветует, я б научился вытупать

А о чем ты хотел бы выступить?

Слава! Не упускай парня! Он выступить хочет!

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

Ваня, вот, послушай хорошего лектора: https://www.youtube.com/watch?v=LcQXXhNT__I

Ж)))

Это вырезки, полностью лкция про Кложуру тоже там есть. Но это - просто чудо природы! :)))

спасибо

обращайся :)

Приветствую товарищи, есть такой вопрос про база данных: Работаю sqlx + postres, использую не http server, а grpc методы, но не суть. Например в 1 секунду одновременно может прийти 50 запросов, но у меня база глобальная, в main я его открыл, и держу в memory: var db *sqlx.DB func AccountFor(db *sqlx.DB) и просто в каждый запрос передаю его в параметрах, так вот у меня крашит на транзакциях, как работать многопоточно с базой? Сильно гуглю, пока стоящее не нашел?

Делай одну транзакцию, если у тебя атомарные запросы и все такие запросы просто делай в ней . Эта транзакция будет идти через один connect. И, разумеется, счетчик времени, или количества атомарных запросов (по ситуации). Периодически ты должен говорить COMMIT

Делай одну транзакцию, если у тебя атомарные запросы и все такие запросы просто делай в ней . Эта транзакция будет идти через один connect. И, разумеется, счетчик времени, или количества атомарных запросов (по ситуации). Периодически ты должен говорить COMMIT

Может есть пример на gist, github, честно, пока не очень понятно. Пример кода чтоли

К сожалению, в библиотеке Go сделано все так, что подразумеваются только транзакции, на каждую он будет открывать новое подключение к базе. Поправьте, если не прав, но я в это утыкался :(

в го есть пул коннектов

Пример кода - звучит слишком по-индийски

Слава, есть пул коннектов и размером даже можно рулить. Но библиотека думает, что любой запрос - это транзакция, а для нее надо открыть соединение с базой :(

Например как эту задачу я решил бы в Swift или Object-C, просто создаю global queue очередь только для database, и все операций по базе, кидаю в block в эту очередь: queue.async{}

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

И эта функция, как можно понять. держит один коннект с базой.

Или я не понял, и ты о чем-то другом?

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

code example pls, примерно хоть, наводку, не догоняю

У меня нет готового примера

У sqlx вроде есть connection pool: http://jmoiron.github.io/sqlx/#connectionPool

не оно?

По сути, я предлагаю тебе сделать на Go функцию, которая обрабатывает очередь запросов, как ты привык. Но она должна периодически говорить Commit

в общем, SQL-библиотека - это не ORM, а довольно низкоуровневое средство, на надо думать, что она все сделает за тебя и даже думать, что сделает правильно :(

И эта функция, как можно понять. держит один коннект с базой.

суть: многопоточно работать с базой, база одна в memory, тоесть там может 5 goroutine но база одна, и чтобы на transactions(update, create) не panic был

А у тебя panic? Тогда я точно не понял вопроса. Сначал свой код покажи, как ты хотел это сделать?

func (s *server) CreatePayment(ctx context.Context, paymentReq *pb.PaymentRequest) (*pb.PaymentRequest, error) { unique_key, storeError := model.StorePayment(db, paymentReq) if storeError != nil { return nil, storeError } return paymentReq, nil } func StorePayment(db *sqlx.DB, payment *pb.PaymentRequest) (uint64, error) { tx := db.MustBegin() var lastInsertId uint64 err := tx.QueryRow("INSERT INTO payments " + "(total_order_price, discount, total_price_with_discount) " + "VALUES($1, $2, $3) returning payment_id;", payment.TotalOrderPrice, payment.Discount, payment.TotalPriceWithDiscount).Scan(&lastInsertId) CheckErr(err) commitError := tx.Commit() CheckErr(commitError) return lastInsertId, nil } сейчас все в одном потоке

а можно в тройных бэктиках?

А лучше на pastebin хотя бы ;D

содомия какая-то

коллеги, вы бы спросили для начала, что такое "крашит на транзакциях"

http://pastebin.com/W6Maddm4

А лучше на pastebin хотя бы ;D

в печатном виде, и нужное подчеркнуть

http://pastebin.com/W6Maddm4

Во, тут хоть как-то что-то прочитать можно

так это

что с транзакциями не так?

да, кажется тут с ТЦП/ИП и вобще этой проблематикой что-то не так. До баз данных дело еще даже не у всех доходит.

что с транзакциями не так?

Суть в том что таких мест много, тоесть одновременно StorePayment, StoreCustomer, StoreSupplier может вызвать, а db *sqlx.DB только одно, и все, лови panic, тоесть crash

func (s *server) CreatePayment(ctx context.Context, paymentReq *pb.PaymentRequest) (*pb.PaymentRequest, error) { unique_key, storeError := model.StorePayment(db, paymentReq) if storeError != nil { return nil, storeError } return paymentReq, nil } func StorePayment(db *sqlx.DB, payment *pb.PaymentRequest) (uint64, error) { tx := db.MustBegin() var lastInsertId uint64 err := tx.QueryRow("INSERT INTO payments " + "(total_order_price, discount, total_price_with_discount) " + "VALUES($1, $2, $3) returning payment_id;", payment.TotalOrderPrice, payment.Discount, payment.TotalPriceWithDiscount).Scan(&lastInsertId) CheckErr(err) commitError := tx.Commit() CheckErr(commitError) return lastInsertId, nil } сейчас все в одном потоке

Боюсь, ты спросил не тот вопрос. Согласись?

Mo, ты сообщение err от базы берешь при выполнении вызова библиотеки? Что в этом сообщении?

Суть в том что таких мест много, тоесть одновременно StorePayment, StoreCustomer, StoreSupplier может вызвать, а db *sqlx.DB только одно, и все, лови panic, тоесть crash

чушь

а можно стектрейс?

только не в канал!

только не в канал!

ачетакова?

ну... как-то... даже не знаю... если тут так принято, то почему нет? :)

не принято

сейчас восоздам данную проблему, stacktrace

для начала хоть воссоздай, что за паника такая :)

Че то не получается пока, работает, ни одной ошибки, продолжаю поиски...

в стек трейсе (или в ошибке) обычно есть ответ на все вопросы, лучше их не игнорировать

Слава, что можешь сказать про mutex? Они правда так глобально все замедляют?

Олдовые Сишники говорят, что mutex - это дико роняет производительность при каждом разе использования. А вот юзал и не чувствовал. Или и правда это так плохо?