Восприимчивость Gradle к командной строке

Возникла острая необходимость в ядре для тестов использовать различные БД, и для этого нужно, чтобы gradle передавал конфиг в spingboot. Решение, казалось, лежало на поверхности — использовать параметры командной строки: -Dparameter=value, но как оказалось, это не работает для грэдла (хотя отдельно для исполнения тестов работает).

После гугления нашлось такое решение:

test {
    //https://www.credera.com/blog/technology-insights/java/gradle-profiles-for-multi-project-spring-boot-applications/
    // В аргументах грэдлу передавать через -P
    // -Pproperty.name=value
    // без парамаметров будет браться конфиг из application.properties

    project.ext.applyPropertyIfExists = { propertyKey ->
        if(project.hasProperty(propertyKey)) {
            systemProperties[propertyKey] = project.getProperty(propertyKey)
        }
    }
    applyPropertyIfExists('spring.profiles.active')
    applyPropertyIfExists('spring.datasource.url')
    applyPropertyIfExists('spring.datasource.username')
    applyPropertyIfExists('spring.datasource.password')
}

 

Пока я на испытательном сроке, то прежде чем закомитить, надо показать код сеньору.

Он посмотрел и сказал — норм, но надо сделать проще ))

test {
    //для -Dproperty=value
    systemProperties(System.getProperties())
}
Когда позвали на помощь сеньора.

Маленькое дерево с большой проблемой

Прошло 2 месяца — в Котлине освоился, но React еще доводит до кипения.
На днях случилось: воевал я с новым компонентом от Ant.design — TreeSelect, ну чтобы выбирать значение в дереве. Нарисовал быстро, а как данные загрузить до прорисовки понял не сразу. Выход нашелся, когда уже глаза покраснели — рисовать спин, а загружать в componentDidMount. Все это успешно отладилось на песочнице, но когда доехало в прод, начались дииикие тормоза. А все из-за того, что записей в дереве получилось в 10 раз больше. А как дерево строится? Ну как обычно рекурсией, а это самая медленная из операций — цикл в цикле, а еще вся эта радость крутиться не на сервере, а на клиенте. Поэтому скорость упала не в 10 раз, а в 100.
Короче, я попал на самую распространенную задачу при отображении дерева с большим количеством элементов. Обычная практика — выделился узел, дети подтянулись. Но этот TreeSelect этот принимает на вход только целое дерево и не умеет подгружать узлы по запросу.

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

Коктейль из Java, Kotlin и ReactJS

Итак, я сменил галеру место работы. И, неожиданно, технологии. Java есть, номинально, но на текущий момент, плотно уже 3 недели изучаю Kotlin в связке с ReactJS.

До этого я конечно слышал, про них, но не пробовал. По котлину пару обучающих видео посмотрел и вперед.

Первые впечатления: точка-с-запятой не нужна, типы указываем после переменной, тернарный оператор урезан и стал «элвис» оператором, статических полей нет, финальная и нефинальная переменные обозначаются val и var, функции заменили методы, все классы по-умолчанию финальные. Аааааа-ааа-а!!!

Пример:

fun getPrintTemplate(data: Map<String, Any?>, metadata: MutableList<String> = mutableListOf()): MutableList<String> {
 data.forEach { entry ->
            val value = entry.value
            if (value is Collection<*> && value.isNotEmpty()) {
                (value.first() as Map<String, Any?>)
                        .keys
                        .forEach { subKey -> metadata.add("${entry.key}.$subKey") }
            }
            if (value is Map<*, *>) getPrintTemplate(value as Map<String, Any?>, metadata)
}
    return metadata
}

По реакту — это даже не фреймворк, напрямую не пишем? а под котлин это выглядит как работа с обычными классами.
Вот например создаем элемент:

fun RBuilder.downloadLink(fileName: String, dataFunc: suspend () -> String, body: ((RBuilder).() -> Unit)? = null) {
    a {
        attrs.onClickFunction = {
            async {
                val base64data = dataFunc()
                downloadFile(base64data, fileName).invoke()
            }
        }
        if (body != null) {
            body()
        } else {
            +fileName
            +" "
            icon("download")
        }
    }
}

А потом обращаемся к нему:

    row{
        downloadLink(attach[Attachment.displayName], dataFunc = { handleDownload() })
    }

 

В общем как новый язык изучать. Угораздило жеж ))

Тренажеры на каждый день

Пара отличных тренажеров для разминки с нетривиальными задачками.

https://proghub.ru — совсем молоденький, но многообещающий ресурс, выделяется названием. Комментирования нет, но можно предложить свой вариант ответа. По Java совсем мало пока (в режиме тестирования ооп — 10 вопросов, по спрингу — 8), можно пробовать без регистрации.

http://www.quizful.net/tset — ресурс постарше, вопросы поинтереснее и разнообразнее, много тем, можно комментировать.

 

 

Про собеседования

Поменять работу — это как развестись и искать новую жену. А собеседования (не нравится мне это слово, предпочитаю термин «техническая беседа») это как смотрины. Рассматривая новое предложение в крутой компании, мы смотрим на нее как на женщину.

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

Парни, вы же знаете это чувство, когда вам отказала женщина? Самооценка ниже плинтуса? Вот-вот.

Редко, очень редко, когда от смотрин остается приятное чувство, и даже если тебе отказали, то сделали это очень тактично. Вот в таких компаниях хочется работать. К таким даже через полгода еще хочется напроситься на беседуsmile

 

Ароматный Java

Java это не только язык, но и кофе. Не даром чашка горячего напитка является его логотипом.

Наконец-то пришла посылка с тру кофе для джависта  cool

+1? или Зачем ещё один блог программиста?

Ну, во-первых, это красиво…

Если начать с конца, то во всем виноваты умные мессенджеры smile

Надо было созвониться с одним человеком и я кинул ему свой скайп-логин: kapion.ru

А мессенджер принял это имя как ссылку и еще текст и миниатюру подтянул в сообщение. А там вылезло что-то типа «пишу программы на java заказ» и кактус. Это просто был какой-то стандартный шаблон и заголовок с потолка, потому что программы на заказ я не пишу, т.к. работаю в «кровавом энтерпрайзе».

Так не годится, подумал я и решил причесать главную страничку, а там понеслось smile Эта давно зреющая идея вдруг обрела смысл. Вести блоги я начал давно в жж и на драйве, но это все непрофессиональной направленности. Опыта скопилось немало, и им надо делится.

Ну а началось все 4 года назад, когда я доделывая очередной selecion-screen на абапе понял, что больше не хочу и не могу писать под SAP. Это огромная ERP система, сильно повредила мне мозг. Я мог без компа на листочке налабать отчетик с табличками и селектами, знал тайные места, где можно внедриться в стандартный функционал и как можно хакнуть в случае чего кое-какие настройки. Можно почувствовать себя гуру и еще лет 10 клепать отчетики, благо платят за это нормально. Но как программист я понял, что тупею. Меня перестало что-то интересовать в мире IT, кроме смехуечков. SAP это тупик, потому что это закрытая система. Ты не можешь никуда больше применить свой гигантский опыт, а сертификатом можешь подтереться, нигде кроме консалтинговых контор или их клиентов (жертв маркетинга) он не имеет значения.

С тех пор, с 2014 года я взялся за джаву. Она мне всегда была интересна, в первую очередь потому, что на ней основан android. А еще эта заставка при установке JDK — java используется на более 3 миллиардах устройств, ммм :-Р

Эта гибкость меня и подкупила)) Хотя некоторые мои знакомые и друзья посмеялись узнав об этом, утверждая, что java мертва. А я просто посмотрел рынок, посмотрел зп в отрасли, почитал хабр и не стал никого слушать)

И вот сейчас я пишу блог, потому что за 3 года профессиональной работы на java я уже набрался опыта и могу им делиться. К тому же это хорошая мотивация продолжать изучать что-то новое, потому что судьба такая у программистов — необходимость всегда чему-то учиться. И это здорово!

з.ы. подобных блогов миллион, добавлю-ка я еще +1  laugh

Back-End — это магия

Во всем и во всех есть две стороны: черная и белая.
Важно лишь то, какую сторону выбрал ты.
Это определяет все. © Гарри Поттер — Кубок Огня.

Вы наверняка уже слышали эти модные в сфере программирования слова «фронтенд» и «бэкенд», но что за ними стоит? КЭП сообщает, что  фронтенд и бэкенд чаще употребляются в сфере веб-приложений, но это далеко не всегда так. Предлагаю в этом разобраться.

Давайте начнем с определений.

Фронтенд — все, что браузер может читать, выводить на экран и/или запускать. Что касается веб-приложений, то это HTML, CSS, JavaScript и фреймворки на их основе.

Сфера ответственности фронтенд-разработчика охватывает создание пользовательского интерфейса, что в свою очередь подразумевает некоторую иерархию. Это дизайн макета, верстка, адаптация. Важной частью разработки веб-приложения является UI/UX дизайн — то, что в наибольшей степени влияет на первое впечатление пользователя. В эпоху современных веб-приложений, в подавляющем большинстве реализующих некоторую бизнес-логику, их поведение не менее важно, чем внешний вид.

Как фронтенд смотрит на бэкенд

Как фронтенд-разработчик смотрит на бэкенд 🙂

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

Бэкенд — все, что работает на сервере, то есть «не в браузере» или «на компьютере, подсоединенном к сети, который отвечает на сообщения от других компьютеров». Бэкенд — это серверная логика веб-приложения. Здесь реализуется работа с хранилищем данных, поэтому человек, занимающийся разработкой серверной логики, должен иметь навыки работы с базами данных. Именно от бэкенд-разработчика зависит производительность серверного кода, его масштабируемость, безопасность и рациональность.

Как бэкенд отвпечает на запросы

Бэкенд отвечает на запросы

Помимо серверной логики в сферу ответственности бэкенд-разработчика входит отладка и прототипирование с использованием клиентской части приложения. Это влечет за собой необходимость понимания работы стека протоколов TCP/IP, HTTP, REST/SOAP, принципов взаимодействия браузера с веб-приложением.

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

Для бэкенда вы можете использовать любые инструменты, доступные на вашем сервере. Это означает, что вы можете использовать любой универсальный язык программирования: Java, PHP,  Ruby, Python, JavaScript/Node, bash и т.д. Это также означает, что вы можете использовать любые системы управления базами данных, такие как Oracle, MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached и т.д.

Настоящий программист способен разобраться в любой технологии при наличии достаточного времени, но важно выбрать специализацию.

п.с. Выше я не зря упомянул JavaScript/Node. Когда появились NoSQL базы данных, стала стираться граница между фронтенд- и бэкенд- разработчиками.  Стало необязательно учить SQL и верстальщик веб-страниц вполне может тащить данные непосредственно из БД и  реализовывать бизнес логику на клиентской части.