Получи случайную криптовалюту за регистрацию!

StringConcat - разработка без боли и сожалений

Логотип телеграм канала @stringconcat — StringConcat - разработка без боли и сожалений S
Логотип телеграм канала @stringconcat — StringConcat - разработка без боли и сожалений
Адрес канала: @stringconcat
Категории: Технологии
Язык: Русский
Количество подписчиков: 1.71K
Описание канала:

Полезный блог от разработчиков для разработчиков. Наш сайт: howto.stringconcat.com

Рейтинги и Отзывы

3.33

3 отзыва

Оценить канал stringconcat и оставить отзыв — могут только зарегестрированные пользователи. Все отзывы проходят модерацию.

5 звезд

1

4 звезд

1

3 звезд

0

2 звезд

0

1 звезд

1


Последние сообщения

2021-12-14 15:35:58 Еще один шаг сделал Котлин в борьбе с засилием примитивных типов. Котлин 1.5.0 представляет Value Classes.

В чем проблема?

fun calculateAvgSpeed(distance: Int, time: Int) { … }

fun main() {

val weight = 64 // kg
val time = 60 // sec
calculateAvgSpeed(weight, time)
}

Скомпилируется, выполнится без проблем. Ведь Int может представлять все что угодно: время, расстояние, вес и пр. И, скажем в Java нет никакой возможности бороться с этим.

В Котлин были data classes
data class Distance(val distance: Int)
Которые решали эту проблему, но все же в создание они тяжелее примитивных типов: под них надо выделять место в куче, а не в стеке.

Другим вариантом были type alias

typealias Distance = Int
fun calculateAvgSpeed(distance: Distance, time: Int) { … }

но он не спасает от использования примитичного типа вместо Алиса

fun main() {

val weight = 64 // kg
val time = 60 // sec
calculateAvgSpeed(weight, time)
}
Все еще работает :(

И вот теперь нам доступен value class

@JvmStatic
value class Distance(val distance: Int)
Который является как бы оберткой над примитивным типом, а с другой все еще хранится в стеке, а не в куче. А это значит что Garbage Сollector не надо будет беспокоить по-мелочам.

@JvmStatic
value class Distance(val distance: Int)

fun calculateAvgSpeed(distance: Distance, time: Int) { … }

fun main() {

val weight = 64 // kg
val time = 60 // sec
calculateAvgSpeed(weight, time) // does not work anymore
calculateAvgSpeed(new Distance(64), time) // works perfectly
}
```

таким образом можно наконец-то можно навести порядок с примитивными типами
Подробности
440 views12:35
Открыть/Комментировать
2021-12-10 14:17:01 Merry Christmas!!!

В библиотеке log4j под Apache ночью вдруг нашлась 0-day уязвимость, приводящая к удаленному выполнению кода (RCE). К этому всему удовольствию прилагается рабочий PoC, опубликованный на GitHub.

На момент появления PoC у дырки не было даже CVE (сейчас уже есть - CVE-2021-44228). Известно, что уязвимость работает на куче сервисов, к примеру - Steam, iCloud и пр.

Эксплойту подвержены версии Apache log4j вплоть до 2.14.1. Сканирование сети на предмет уязвимых серверов уже идет (странно было бы ожидать другого при наличии рабочего PoC).

В качестве меры смягчения сначала предлагалось обновить log4j до версии 2.15.0-rc1, но буквально в течение нескольких часов был найден способ обхода исправления, поэтому теперь рекомендуют обновлять до 2.15.0-rc2. Кроме того, некоторые инфосек эксперты рекомендуют установить log4j2.formatMsgNoLookups в значение true.

Также LunaSec со ссылкой на китайцев говорят, что эксплойт не работает на версиях JDK выше 6u211, 7u201, 8u191 и 11.0.1.

Ну а вишенка на этом рождественском торте - эксплойт работает на всех версиях Minecraft начиная с 1.8.8.

Apache Foundation пьют валерьянку и молчат.

Merry Christmas, дорогие наши, Merry Christmas!!!
584 views11:17
Открыть/Комментировать
2021-12-03 15:21:21 Моими самыми любимыми фичами в котлине являются null-safety и sealed-классы. Но не всегда мы работаем с модным котлином, иногда приходится брать в руки старую-добрую жабу. И если sealed классы таки завезли, то борьба с нуллами продолжается. С джавы версии 14 NPE стали чуть более информативными, но багов от этого меньше не стало. Остается надеяться только на статанализ. Одно из таких решений — NullAway от Uber. Это плагин для Error Prone, который позволит отловить NPE еще на этапе сборки. Наверное это единственное более-менее вменяемое и актуальное на данный момент решение. Или же есть что-то еще? Будет круто, если поделитесь своим опытом борьбы с NPE в комментариях (желательно успешным, но тут всякое бывает, да).
797 viewsedited  12:21
Открыть/Комментировать
2021-11-03 13:26:15 Статистика и вероятностные методы в разработке

В сентябре на Хабре вышел перевод статьи Сони Сайдеровой о вероятностных прогнозах. Хабро-эксперты по всему на свете обошли её стороной и не закидали какахами, а зря: тема интересная и перспективная.

Статистику применяют для прогнозирования и оценки проектов, а ещё с её помощью можно отслеживать проблемы. Например, предсказывать сбои на проекте до начала пожара и вовремя замечать признаки выгорания у разработчиков. Максимально упрощенно работает так:

Что-то меняем → Смотрим на показатели → Делаем выводы

Например, внедряем CI или меняем архитектуру, а потом смотрим, как меняются трудозатраты на задачу для каждого участника процесса.

Один из авторов канала внедрял статистическое отслеживание динамики процессов разработки. Графики постом выше — было и стало по одному разработчику (исходные данные утеряны, остались только скрины с разным масштабом).
Ось X — количество жоподней на одну задачу.
Ось Y — количество задач, которые заняли соответствующее кол-во жоподней.

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

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

Если вам интересно про прогнозирование и оценки, как-нибудь напишем развернутый пост. Оставляйте комментарии, делитесь мыслями.
982 viewsedited  10:26
Открыть/Комментировать
2021-11-03 13:26:00
Графики к посту о статистике
686 viewsedited  10:26
Открыть/Комментировать
2021-10-28 10:48:57 Свежая пресса, господа!
Только что вышел Technology Radar.

Меня лично в этом выпуске зацепил фокус на том, как команды перестраиваются на удаленную работу.
Trial: Remote mob programming. Говорите что pair programming - слишком затратное дело? Thoughtworks пробует подход, когда вся команда собравшись удалённо работает над сложной задачей

Trial: Single team remote wall. Привыкли к том у что все стены в вашем офисе изрисованы схемами и увешаны стикерами? Ничего не мешает сделать виртуальную стену!

Adopt: Zero trust architecture. Когда я начинаю проект всегда встает вопрос как организовать security внутри кластера. Должны ли мы доверять вызовам, только потому что они ходят внутри защищенного периметра или все таки нет?. Zero trust architecture говорит что доверять мы не должны никому, И защищенный периметр - не лучший вариант

Adopt: 4 key metrics. На самом деле я удивлен, что они только сейчас вошли в adopt. Если вы еще не смотрели на них, то очень советую. Они про то, как померить эффективность доставки software, или при более широкой трактовке как померить эффективность работы команды

И многое другое….

https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2021/10/tr_technology_radar_vol_25_en.pdf
956 views07:48
Открыть/Комментировать
2021-10-20 07:59:04 Новый выпуск technology radar уже готов к выходу. Thoughtworks презентует его online 20 октября в 17:00 по Москве. Регистрация обязательна https://www.thoughtworks.com/en-sg/radar/technology-radar-webinar
3.3K views04:59
Открыть/Комментировать
2021-10-15 10:03:51
Нил Форд, автор fundamental of software architecture, опубликовал новую книгу “The hard parts of software architecture”. В ней он говорит в сущности о трех вещах:
— каждое ваше архитектурное решение это компромисс
— о том, насколько большими должны быть сервисы
— о коммуникации между сервисами

Послушать о книге можно в подкасте Thoughtworks:
https://www.thoughtworks.com/en-sg/insights/podcasts/technology-podcasts/the-hard-parts-of-software-architecture

Книга доступна только в электронном виде, ну и, конечно, только на английском:
https://www.amazon.com/Software-Architecture-Parts-Neal-Ford-ebook-dp-B09H2H5QKC/dp/B09H2H5QKC/ref=mt_other?_encoding=UTF8&me=&qid=1634275068

На самом деле очень сложно найти хорошую книгу по архитектуре. И “Fundamentals of Software Architecture” я прочитал на одном дыхании, а кое-что даже ни один раз. Полагаю, новая книга станет бестселлером!
1.4K viewsedited  07:03
Открыть/Комментировать
2021-10-08 17:02:11 А Женя из @dddevotion вдруг взял и перевёл статью специально для тех, кому лень читать по-английски. За что ему большое спасибо!
1.1K views14:02
Открыть/Комментировать
2021-10-06 18:13:34
Robert Laszczak из Three Dots Labs написал на английском про тёмные века софтверной разработки: https://threedots.tech/post/software-dark-ages/

Роберт описывает классическую ситуацию: все хорошие практики уже давно придуманы, но в компаниях про них не слышали и продолжают поклоняться идолищам. Изменения выкатываются месяцами, микросервисы тонут в зависимостях, никто не знает, какую проблему решает. Ну, всё то, о чём мы сами рассказываем (и во что вляпываемся).

Автор наглядно объясняет, как такая ситуация возникает:

1. Не поняли, что нужно → получили унылое и дохлое.
2. Повторяем 1 пункт, пока не надоест.

Еще Роберт пишет, что делать и почему этого ещё не сделали и, конечно же, проповедует благое DDD.
938 viewsedited  15:13
Открыть/Комментировать