я ж говорю, релизят) скоро будет ченжлог

ченжлог в самой репе обновили

ну это же тупо для ознакомления, а потом доки

Слишком большой временной бойлерплейт

Ребят, а можете посоветовать нормальные видеоуроки по котлину? Кто-то уже сделал?

читай документацию, она на редкость для людей написана

Интересно, сколько в природе продовых серверов с копипастой отсюда http://ktor.io/features/shutdown-url.html )

Нет сейчас доступа к сырцам: как у kotpref реализовано сохранение enum'оф? Через порядок и инту просто?

Нет сейчас доступа к сырцам: как у kotpref реализовано сохранение enum'оф? Через порядок и инту просто?

там, кажется, оба варианта есть

Ktor 0.9.3 зарелизился, обширный список изменений: http://ktor.io/quickstart/migration/0.9.3.html

кто более опытный, зачем нужны все эти виды авторизации, в чем разница между ними ?

https://ktor.io/features/authentication.html

кто более опытный, зачем нужны все эти виды авторизации, в чем разница между ними ?

я не опытный, но наверное выбор, то с чем ты привык работать

Ну почитай

нету опыта работы совсем, но я думаю что 1 - это локальная авторизация (на самом сайте через форму), а другие это типо авторизация через другие сервисы (google, vk..)

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

4 хз

у яндекс есть OAuth

Мне нравится jwt

https://tech.yandex.com/oauth/

Мне нравится jwt

перефразирую: в чем преимущества ?

вот именно по этому я и спросил, интересно что вы используйте

Посмотри на jwt)

вот именно по этому я и спросил, интересно что вы используйте

То, что нужно в данной ситуации. Если бы одна штука была строго лучше других, других бы не стало.

для сайта авто школы ))

перефразирую: в чем преимущества ?

кто более опытный, зачем нужны все эти виды авторизации, в чем разница между ними ?

Разные задачи. 1. Basic - простейшая, можно закрыть за браузерной формочкой админку например 2. Digest - продвинутая Basic, без передачи пароля в открытом виде по каналу (актуально если https нету) 3. Stateless в простейшем виде 4. LDAP - это такая интерпрайзная штука в организациях 5. Для социалочек используется, чтобы давать доступ третьим лицам, при этом не передавать им пароль

вот про 5 знал ), спасибо большое

Basic и Digest например по стандарту используются в WebDav, там прикрутить что-то другое не так просто

можно сконектица к диску яндекс и хранить там что то через WebDav ?

допустим заливать видео через сайт

можно сконектица к диску яндекс и хранить там что то через WebDav ?

ну чтобы сконектиться тебе придется пройти аунтентификацию по одному из спобов: Digest или Basic

ну да

ситуация больше похожа на OAuth

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

С JWT не все так просто на самом деле, там и инвалидировать токены нужно (может стоять такая задача), и рефреш токены использовать (вот это хорошо https://habr.com/company/Voximplant/blog/323160/ статья объяснит, правда не уверен что я нашел ту самую). Если у тебя не какие-то там супер распределенные микросервисы или 3-rd party клиенты то может он и не нужен, а может и нужен, все таки удобно иметь id клиента в токене.

Но типо не понацея. А еще говорят что XSS плохо для ваших JWT, типо можно украсть и слать все подряд на бекенд. Но JWT в хидере удобно - не нужно думать про CSRF.

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

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

md5 ?

jbcrypt

blowfish

md5 поиском в гугле ломаются

хорошо, спасибо

Пришел я на проект, а там хеши встроенных юзеров лежали прям в репе, в SQL для загрузки в базу тип при накатке свежего инстанса. Загуглил хешики - и 3-4х один прям нашелся.

Поэтому сейчас blowfish с солью

а это сойдет https://hashids.org/kotlin/ ?

искал blowfish, надкнулся на это

jbcrypt

Вот же

Всем доброго времени суток, подскажите пожалуйста, делаю первое прилождение под андроид, такое дело, перетаскиваю элемент (кнопку) в дизайнере на рабочую область, и тут же получаю ошибку "This view is not constrained. It only has designtime positions, so it will jump to (0,0) at runtime unless you add the constraints", подскажите пожалуйста, как это фикситься ? Я слышал что лучше сразу все элементы описывать в xml, но как быть с позиционированием элементов на экране ? Направьте пожалуйста в нужное русло, где что почитать, всем заранее огромное спасибо за ответы!

Всем доброго времени суток, подскажите пожалуйста, делаю первое прилождение под андроид, такое дело, перетаскиваю элемент (кнопку) в дизайнере на рабочую область, и тут же получаю ошибку "This view is not constrained. It only has designtime positions, so it will jump to (0,0) at runtime unless you add the constraints", подскажите пожалуйста, как это фикситься ? Я слышал что лучше сразу все элементы описывать в xml, но как быть с позиционированием элементов на экране ? Направьте пожалуйста в нужное русло, где что почитать, всем заранее огромное спасибо за ответы!

@android_ru

@android_ru

ок, спасибо!

Java Magazine проводит опрос разработчиков, предлагаю и вам поучаствовать в нём: https://snykteam.typeform.com/to/V4LOUZ?utm_source=dailykotlin_tl

можно сконектица к диску яндекс и хранить там что то через WebDav ?

Да

так что если выучить kotlin, можно быстро выучить swift, а если выучить swift, то открывается много дверей))

Каких дверей?

Каких дверей?

дверей=возможностей

Каких возможностей, кроме кодить по айос?

Так себе язычок имхо

Тензор Kappa

Одни параметры наркоманские в функциях чего стоят

Говорят дженерики у них тоже говно

Интервалы, интервалов сюда!

1..<5

Написал и почуствовал облегчение

Swift ничем особо от Kotlin не отличается. Другое дело, что когда kotlin native заработает в полную силу, можно будет писать приложения под все мобилки и веб одновременно, думаю народ эту возможность не упустит.

Лично меня native совсем с другой стороны интересует.

Swift ничем особо от Kotlin не отличается. Другое дело, что когда kotlin native заработает в полную силу, можно будет писать приложения под все мобилки и веб одновременно, думаю народ эту возможность не упустит.

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

Ну это дешевле чем использовать тех кодогенерирующих монстров, которых используют сейчас.

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

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

Ага, и получится как всегда, шаг вправо, шаг влево - расстрел

да

А куда без этого?

Использовать нативные для платформы языки ¯\_(ツ)_/¯

Дорого

Очень спорно, в дальнейшем превозмогание ограничений абстракции может обойтись дороже

Опять, вопрос масштаба. Если интерфейсная часть существенно больше логической, то можно продублировать логику на разных языках. Если хочется странного, то других вариантов нет. Но если это тупо стандартные окошки, то почему нет? JavaFX отлично справляется, а у нее для каждой системы свой нативный бэкэнд.

Кроме того, если вдруг разработка на kotlin будет такой же удобной, как разработка на swift, то зачем учить два языка, когда можно учить один?

Лично мне до лампочки, я сейчас мобильной разработкой не занимаюсь. Но развитие экосистемы конечно очень важно.

Дорого

я считаю эти затраты вполне оправданы, и даже не хочу смотреть в сторону кросс-платформенности

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

Кроме того, если вдруг разработка на kotlin будет такой же удобной, как разработка на swift, то зачем учить два языка, когда можно учить один?

По той же причине, почему остальные мобильные фреймворки дохнут. У эпла есть куча тулов - дебагеры, профайлеры, отладчики и т.п. И все это не будет нормально работать с ллвм кодом внутри другой виртуалки. И вопрос зачем учить язык тупиковый. Чтобы писать под иос надо знать платформу и ее экосистему. Язык - самая элементарная вещь, из тех что нужны для нормальной разработки приложух под мобилку.

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

По той же причине, почему остальные мобильные фреймворки дохнут. У эпла есть куча тулов - дебагеры, профайлеры, отладчики и т.п. И все это не будет нормально работать с ллвм кодом внутри другой виртуалки. И вопрос зачем учить язык тупиковый. Чтобы писать под иос надо знать платформу и ее экосистему. Язык - самая элементарная вещь, из тех что нужны для нормальной разработки приложух под мобилку.

В этом как раз и отличие подхода Kotlin/Native. Нет никакой другой виртуалки, а К/N выдает такой же LLVM код как и Swift, поэтому инструменты apple (отладчики профайлеры и т.п.) работают с ним из коробки по модулю ограничений того, что в XCode нельзя написать plugin который бы, например, сделал правильную подсветку и навигацию для Kotlin кода. (Apple головного мозга — неизличимая болезнь)

?

@relizarov вопрос о ретроспективе : у вашей команды не возникало мысли сделать K/N по типу Go - сборки бинаря с рантаймом?

Так оно по типу Go и сделано. Просто рантайм очень тонкий.

В этом как раз и отличие подхода Kotlin/Native. Нет никакой другой виртуалки, а К/N выдает такой же LLVM код как и Swift, поэтому инструменты apple (отладчики профайлеры и т.п.) работают с ним из коробки по модулю ограничений того, что в XCode нельзя написать plugin который бы, например, сделал правильную подсветку и навигацию для Kotlin кода. (Apple головного мозга — неизличимая болезнь)

"Богоподобнейший блокнот, они зовут его XCode"

Так оно по типу Go и сделано. Просто рантайм очень тонкий.

Просто вижу LLVM в вашем ответе) K/N умеет в разные бэкэнды?

Swift ничем особо от Kotlin не отличается. Другое дело, что когда kotlin native заработает в полную силу, можно будет писать приложения под все мобилки и веб одновременно, думаю народ эту возможность не упустит.

swift-то уже сейчас есть нативно; на medium была серия статей о том, как написали приложение под android на swift

Тогда это прям совсем интересно получается

Просто вижу LLVM в вашем ответе) K/N умеет в разные бэкэнды?

WebAssembly же ещё

Прям контрибьютить захотелось, если бы умел)

WebAssembly же ещё

Всё через LLVM. К/N выдает LLVM биткод и дальше можно куда угодно, куда в LLVM есть бэкенд (ARM, x86, WebAssembly и т.п.)

Всё через LLVM. К/N выдает LLVM биткод и дальше можно куда угодно, куда в LLVM есть бэкенд (ARM, x86, WebAssembly и т.п.)

А, точно. Получается, K/N будет гвоздями прибит к LLVM?

И в бинарь тоже через LLVM?