всем привет, вот есть картинка data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAA.... как ее записать в файл ?

https://www.google.com/search?q=golang+base64+to+file&oq=golang+base64+to+file&sourceid=chrome&ie=UTF-8

вот так

думаю, первые 10 ссылок подойдут :)

а подскажите еще какой аналог параметра curl -T в go ?

а подскажите еще какой аналог параметра curl -T в go ?

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

:D

вероятность 164%

вот Саша, придёшь на собеседование, а у тебя спросят — уважаемый, а что значит параметр -X у курла?

вот Саша, придёшь на собеседование, а у тебя спросят — уважаемый, а что значит параметр -X у курла?

X. не T

а подскажите еще какой аналог параметра curl -T в go ?

-T, —upload-file FILE Transfer FILE to destination google => golang http client upload file

там ещё просят

как минимум два варианта хотют

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

плохо, когда ты родился в 2000 и лезешь программировать ) лени слишком много

all thumbs

Есть поинтер. Нужно удалить объект на который он ссылается. Как сделать в го такое? Или сборщик мусора это сделает сам? З.Ы. Пришёл с с/спп

явно освобождать память не надо

Есть поинтер. Нужно удалить объект на который он ссылается. Как сделать в го такое? Или сборщик мусора это сделает сам? З.Ы. Пришёл с с/спп

https://github.com/golang/go/wiki/Articles#pointers-references-and-memory-management

GC собирает все объекты, на которые нет ссылок

Приравнять поинтер nil

Приравнять поинтер nil

Как я понимаю, нет разницы, приравнять поинтер к nil или выдать ему новый адрес?

Как я понимаю, нет разницы, приравнять поинтер к nil или выдать ему новый адрес?

да

С точки зрения удаления объекта разницы нет. Главное, чтобы на объект никто не ссылался

Спасибо, ребят

nil делается ссылке на объект, а счётчик ссылок декрементится также при выходе из scope

Киньте ссылочку про то как изменять тайтл консоли

Друзья, как живете с медленными go регулярками?

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

а где то вообще есть быстрые регулярки? :)

а где то вообще есть быстрые регулярки? :)

В Php же. Даже в питоне в 2 раза быстрее по бенчмаркам если смотреть

Алёша классика же https://s-media-cache-ak0.pinimg.com/originals/1b/b9/98/1bb99826e5264bc72e24f054ab67be1e.jpg

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

гофаны, а https://github.com/go-kit/kit юзает кто? поделитесь впечатлениями

Мы юзаем, но совсем немного. Нам не понравилась концепция эндпоинтов.

для апишек же самый сок

Если нужно просто дергать коллбеки, то да.

Мы юзаем, но совсем немного. Нам не понравилась концепция эндпоинтов.

а чем именно? то что для crud не очень удобно?

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

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

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

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

просто можно все на том же эхо/чи/джине сделать, но писанины много бойлерплейтной имхо

посмотри еще https://github.com/micro/go-micro/

писанины на го-ките будет меньше?

писанины на го-ките будет меньше?

надеюсь

посмотри еще https://github.com/micro/go-micro/

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

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

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

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

https://github.com/koding/kite

еще такое есть

ага, делай один апи метод -один фреймвёрк ?

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

ну пока планов по расширению нет :) на старте тоже усложнять не хочется

ну пока планов по расширению нет :) на старте тоже усложнять не хочется

тогда монолит)))

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

не лучше, а проще )

пока нет скилла с микросервисами, риск написания говна выше

пока сделает свои 1700 микросервисов и скилы появятся на следущие 1700 микросервисов

Друзья, как живете с медленными go регулярками?

А что с ними прямо не так? Где есть свежий бенч с наиболее актуальными тестами?

пока сделает свои 1700 микросервисов и скилы появятся на следущие 1700 микросервисов

уверен ли ты, что он сделает столько?))

А что с ними прямо не так? Где есть свежий бенч с наиболее актуальными тестами?

все любят сферического коня в вакууме

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

монолит скейлить тяжело :) хотя опять же, как написать...

монолит скейлить тяжело :) хотя опять же, как написать...

Базу скейлить тяжело, особенно, когда транзакции нужны.

уверен ли ты, что он сделает столько?))

ага, скил не замечать. что говнячишь пока говнячишь может появится раньше

ERROR: S client not available

скейлить все тяжело, что монилит, что сервисы

ну и дробить надо с умом на микросервисы. что бы не было вот так:

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

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

10 слайд https://www.microservices.com/talks/scaling-uber-from-1-to-100s-of-services/

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

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

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

А что с ними прямо не так? Где есть свежий бенч с наиболее актуальными тестами?

Как вариант тут, в тесте в 2 раза медленнее чем в питоне, и то для бенча взяли сторонний пакет , который делает порт к сишной либе pcre. А стандартные go regex еще в 2 раза медленнее, чем pcre http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=python3

так тест устарел уже

Как вариант тут, в тесте в 2 раза медленнее чем в питоне, и то для бенча взяли сторонний пакет , который делает порт к сишной либе pcre. А стандартные go regex еще в 2 раза медленнее, чем pcre http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=python3

а есть пример кода на го?

а есть пример кода на го?

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

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

ага. кликнулось. с телефона просто тупил :)

http://benchmarksgame.alioth.debian.org/u64q/program.php?test=regexredux&lang=go&id=2

https://youtu.be/q1h2g84EX1M?t=44 1700 убер микросервисов

Там другой движок, рассчитанный на большой объем текста: The regexp implementation provided by this package is guaranteed to run in time linear in the size of the input. (This is a property not guaranteed by most open source implementations of regular expressions.) For more information about this property, see http://swtch.com/~rsc/regexp/regexp1.html

так тест устарел уже

Да,тот тест наверное в 2013 делался:-)

https://golang.org/pkg/regexp/

мне про регекс вот это нравится:

As Rob Pike points out, the benefit of regular expressions is their dynamic nature. If you know what you’re going to be matching, you can do better. Sometimes doing better just means a for loop with an if check.

правду говорит

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

Там другой движок, рассчитанный на большой объем текста: The regexp implementation provided by this package is guaranteed to run in time linear in the size of the input. (This is a property not guaranteed by most open source implementations of regular expressions.) For more information about this property, see http://swtch.com/~rsc/regexp/regexp1.html

тоже дело говорят

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

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

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

они оба компилруются в машинный код тут всё дело в реализации

pcre весь оптимизированный, там какие то вещи за экспоненту находит. но большинству оно не надо же

кому нужна скорость:

If Go’s regular expression engine turns out to be the bottleneck, you can use ragel to generate the state machine to match your regexp ahead of time. Rather than being interpreted through the regexp engine, ragel produces Go code that can be compiled into your package. This can easily give 7x-10x speedups.

https://medium.com/@dgryski/speeding-up-regexp-matching-with-ragel-4727f1c16027

As Rob Pike points out, the benefit of regular expressions is their dynamic nature. If you know what you’re going to be matching, you can do better. Sometimes doing better just means a for loop with an if check.

Дак условием иф циклами фор можно заменить регулярки?

Дак условием иф циклами фор можно заменить регулярки?

ну смотря какие регулярки :) думаю что большинство регулярок, которыми там парсят почту/домены/номера телефонов - можно и нужно и будет быстрее.

Ребятушки, посоветуйте, че почитать из книжек по поводу веб сервисов и собсно самого go?