У меня какое-то нехорошее впечатление от вашего саппорта и после него писать куда-то совсем не хочется.
Кстати, года полтора назад было лучше, когда я сам себе покупал одну лицензию — и помогали и советовали.
Теперь, вроде как enterprise, аккаунт на ютреке купили на год вперед — по рабочей почте молчат(вопросы о том, что молчат, заданные с другой почты, игнорируются), по обычной отвечают через раз и то отписками какими-то.
Товарищи из JetBrains, у меня была лицензия PhpStorm, валидная до 20 October 2014, но продлять я её не стал — хватало IDEA, купленной у вас на «распродаже конца света», да и с php не так часто приходилось работать.
Сейчас снова хочу купить лицензию PhpStorm- всё равно, продление или новая, но! Продление мне ваша система хочет сделать не очень, гхм, годовое: до 19 October 2015, так что я бы лучше купил новую лицензию.
Но новую лицензию я купить не могу, потому что "You already have the license suitable for most current version of the product. Would you like to proceed with an upgrade subscription renewal instead?" на который может быть только ответ да.
Вопросы:
Если я еще год подожду, мне придется делать продление два раза?!
Никакой возможности купить новую лицензию для почты, на которой уже была лицензия нет?
PS: Речь идет о лицензии индивидуального разработчика.
Я не понимаю, в чем проблема обновлять купчу роботом?
Есть хромиум, есть вебкит. Люди давно уже используют штуки вроде phantomjs для тестирования сайтов и реальной эмуляции юзера. За какие-нибудь 100 строк кода очень просто пишется бот/парсер ничем не отличающийся от пользователя.
В данном примере программисту, пишущему автоматическое средство совершенно плевать как и что работает в рекаптче — может человек, может робот.
Почему это будет дорого? Ведь .NET и Java используют именно такую модель обработки ошибок.
Go не JAVA и не .NET. Предполагается, что модель Go в области обработки ошибок это эволюция. Есть механизм panic, есть механизм Error.
Исключения в Go не нужны. И нужно очень извратить свой мозг, чтобы они появились(типа той реализации, что я привел).
О каком геморрое вы говорите?
Есть такая ситуация, которая ведет к боли обычно — попытка перенести привычный опыт на всё новое. Go не про огромные системы с DI, не про абстрактные классы и кучи фабрик. Он про решения больших задач маленькими пакетами. Во-всяком случае я в этом уверен.
И маленькие пакеты при вызове своих функций могут вернуть ошибку.
И почему это будет не Go-way?
Вы можете посмотреть на случаи использования panic в стандартной библиотеке.
У меня на работе демон с 30k строк только моего кода крутится, написанный на Go и я не испытал трудностей или проблем с обработкой ошибок. Паника используется тогда, когда мы не можем дальше продолжать работать и это правильно.
Я бы вообще порекомендовал попридежать panic на время первичного знакомства с языком.
По-поводу дорого — я думаю написать статью на недельке по-поводу ошибок, почему они именно так сделаны и про panic-recovery тоже. С бенчмарками. И примерами из стандартной библиотеки.
Возможно, я немного резок, но это потому, что не хочется, чтобы перековали приятный и умный язык на какую-нибудь JAVA.
По-поводу return val,val,val могу посоветовать только использовать именованные возвращаемые параметры.
Не забывайте только о разнице между := и =, хотя по-моему новые версии компиляторов уже сообщают о ошибках типа %var% is shadowed during return
Или можно так:
func foo() (err error) {
var v bool
if v1, err = baz(); err == nil {
if v, err = bar(); err == nil {
println("value is", v, v1)
}
}
return
}
Правда мне кажется, что такие кульбиты выглядят похуже проверки возвращаемого err на nil.
Но во-первых это будет дорого. Во-вторых породит кучу геммороя. В-третьих будет совсем не Go-way и с вашим кодом никто работать не будет.
Парадигму Go в отношении ошибок обрабатывайте и работайте, вашу мать, с ошибками там, где они происодят нужно либо принять, либо забыть про язык.
Паника нужна тогда, когда действительно паника. Мы не можем дальше работать, мы не знаем, что делать — всё пропало.
Ребят, а что вы вкладываете в понятие «социальная сеть»?
А то после фраз вроде
абсолютно все члены команды имеют как минимум две социальные сети в своем портфолио
начинаешь думать, что родился очередной buzzword типа highload/web2.0/cloud.
Написать что-то типа твиттера это не проблема, здесь же все это понимают, да?
Написать что-то типа vk.com это не проблема, это же тоже очевидно, да?
Инстаграм не революция в обработке фотографий, верно?
Веселье и угар начинаются когда это нужно масштабировать. В масштабировании всегда кроется всё самое интересное, потому что одна история твиттер для десяти тысяч человек и другая совсем для десяти миллионов.
Также понятно, что написать фронтенд над API социальной сети и «иметь соц. сеть в портфолио» это чертовски разные вещи.
А что не так с обработчиком ошибок?
Опишите кейс, который вызвал трудности. Не считаю себя go-гуру, но пара демонов в продакшне имеется, последний достаточно жирный по коду.
и только не надо про обленились уже минуту подождать не могут, это действительно сильно замедляет разработку
Нет, тут я согласен. Минута это много.
С другой стороны, c++, особенно на больших проектах дисциплинирует. Chromium, например раз в 15 секунд не попересобираешь ;)
на Юнити ничего лишний раз компилировать/перекомпилировать не нужно
Окей, тогда почему мне нужно вечно пересобирать проект, если Epic Games описывают подобную фичу:
Make updates to your gameplay code while the game is running using Unreal Engine 4's popular Hot Reload feature. This tool allows you to edit C++ code and see those changes reflected immediately in-game without ever pausing gameplay.
мы имеем тонну C++ кода без полноценного скриптового движка
Это в общем-то не так уж и плохо. Если вам захочется писать скрипты не на c++, то всегда можно засунуть LUA, это не займет много времени.
Unity подерживает C#, JavaScript and Boo. Первый мне нравится, но противопоставлять его c++ при разработке игр я бы не стал. Про Boo ничего не слышал.
и код, который удачно «заворачивается» в бандлы
Думаете, у UE4 есть какая-то проблема с модульностью?
Тоесть UnrealScript они выпилили?
Я смотрел скринкасты от эпиков(немного) по UE4 и не сказал бы, что там уж совсем всё по-хардкору.
Вы щупали его или говорите на основе личных ощущений?
Кстати, года полтора назад было лучше, когда я сам себе покупал одну лицензию — и помогали и советовали.
Теперь, вроде как enterprise, аккаунт на ютреке купили на год вперед — по рабочей почте молчат(вопросы о том, что молчат, заданные с другой почты, игнорируются), по обычной отвечают через раз и то отписками какими-то.
Сейчас снова хочу купить лицензию PhpStorm- всё равно, продление или новая, но! Продление мне ваша система хочет сделать не очень, гхм, годовое: до 19 October 2015, так что я бы лучше купил новую лицензию.
Но новую лицензию я купить не могу, потому что "You already have the license suitable for most current version of the product. Would you like to proceed with an upgrade subscription renewal instead?" на который может быть только ответ да.
Вопросы:
PS: Речь идет о лицензии индивидуального разработчика.
Может быть я что-то упустил?
Есть хромиум, есть вебкит. Люди давно уже используют штуки вроде phantomjs для тестирования сайтов и реальной эмуляции юзера. За какие-нибудь 100 строк кода очень просто пишется бот/парсер ничем не отличающийся от пользователя.
В данном примере программисту, пишущему автоматическое средство совершенно плевать как и что работает в рекаптче — может человек, может робот.
Чтобы добавить кнопку нужно просто расширние на написать. На js.
Go не JAVA и не .NET. Предполагается, что модель Go в области обработки ошибок это эволюция. Есть механизм panic, есть механизм Error.
Исключения в Go не нужны. И нужно очень извратить свой мозг, чтобы они появились(типа той реализации, что я привел).
Есть такая ситуация, которая ведет к боли обычно — попытка перенести привычный опыт на всё новое. Go не про огромные системы с DI, не про абстрактные классы и кучи фабрик. Он про решения больших задач маленькими пакетами. Во-всяком случае я в этом уверен.
И маленькие пакеты при вызове своих функций могут вернуть ошибку.
Вы можете посмотреть на случаи использования panic в стандартной библиотеке.
У меня на работе демон с 30k строк только моего кода крутится, написанный на Go и я не испытал трудностей или проблем с обработкой ошибок. Паника используется тогда, когда мы не можем дальше продолжать работать и это правильно.
Я бы вообще порекомендовал попридежать panic на время первичного знакомства с языком.
По-поводу дорого — я думаю написать статью на недельке по-поводу ошибок, почему они именно так сделаны и про panic-recovery тоже. С бенчмарками. И примерами из стандартной библиотеки.
Возможно, я немного резок, но это потому, что не хочется, чтобы перековали приятный и умный язык на какую-нибудь JAVA.
Не забывайте только о разнице между := и =, хотя по-моему новые версии компиляторов уже сообщают о ошибках типа %var% is shadowed during return
Или можно так:
Правда мне кажется, что такие кульбиты выглядят похуже проверки возвращаемого err на nil.
Вы можете написать что-то типа:
Но во-первых это будет дорого. Во-вторых породит кучу геммороя. В-третьих будет совсем не Go-way и с вашим кодом никто работать не будет.
Парадигму Go в отношении ошибок обрабатывайте и работайте, вашу мать, с ошибками там, где они происодят нужно либо принять, либо забыть про язык.
Паника нужна тогда, когда действительно паника. Мы не можем дальше работать, мы не знаем, что делать — всё пропало.
А то после фраз вроде
начинаешь думать, что родился очередной buzzword типа highload/web2.0/cloud.
Написать что-то типа твиттера это не проблема, здесь же все это понимают, да?
Написать что-то типа vk.com это не проблема, это же тоже очевидно, да?
Инстаграм не революция в обработке фотографий, верно?
Веселье и угар начинаются когда это нужно масштабировать. В масштабировании всегда кроется всё самое интересное, потому что одна история твиттер для десяти тысяч человек и другая совсем для десяти миллионов.
Также понятно, что написать фронтенд над API социальной сети и «иметь соц. сеть в портфолио» это чертовски разные вещи.
Опишите кейс, который вызвал трудности. Не считаю себя go-гуру, но пара демонов в продакшне имеется, последний достаточно жирный по коду.
Нет, тут я согласен. Минута это много.
С другой стороны, c++, особенно на больших проектах дисциплинирует. Chromium, например раз в 15 секунд не попересобираешь ;)
Спасибо за ответ.
Но я думаю, что Epic вполне способны повлиять на раскладку на рынке движков. Посему и спрашивал кто что считает по этому поводу.
Окей, тогда почему мне нужно вечно пересобирать проект, если Epic Games описывают подобную фичу:
Это в общем-то не так уж и плохо. Если вам захочется писать скрипты не на c++, то всегда можно засунуть LUA, это не займет много времени.
Unity подерживает C#, JavaScript and Boo. Первый мне нравится, но противопоставлять его c++ при разработке игр я бы не стал. Про Boo ничего не слышал.
Думаете, у UE4 есть какая-то проблема с модульностью?
Я смотрел скринкасты от эпиков(немного) по UE4 и не сказал бы, что там уж совсем всё по-хардкору.
Вы щупали его или говорите на основе личных ощущений?