Привет, Хабр! Меня зовут Глеб, я Java-разработчик в Сбере. Сегодня я хочу рассказать про исторический контекст двух фундаментальных подходов к системе типов в программировании.

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

При динамическом же подходе эта информация для нас открывается только во время выполнения программы (run-time) — это даёт больше гибкости и потенциального удобства при написании кода, однако влечёт за собой множество очевидных проблем: любая ошибка, связанная с типами данных, просто не будет выявлена на этапе компиляции и потребует дополнительного тестирования.

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

Привет, Хабр!

Недавно я понял, что не знаю, что такое Hadoop.

(На этом моменте становится понятно, что данная статья ориентирована на людей, которые не имеют экспертизы и реального опыта взаимодействия с продуктами экосистемы Hadoop)

Сам я являюсь разработчиком, и ежедневно взаимодействую с различными СУБД – в основном, с пресловутой PostgreSQL. Каково же было мое удивление, когда я узнал, что на проде в эту БД данные попадают не напрямую – а с какого-то Greenplum, а туда они, в свою очередь, приходят с некоего Hadoop.

В этот момент я решил узнать, чем обоснована необходимость использования этих инструментов и что они из себя представляют.

Привет, Хабр!

Буквально 20 минут назад прочел статью - Сгенерированный ИИ код сделает вас плохим программистом. И у меня созрела мысль, которую я до этого нигде не читал. Может я невнимательный, а может и действительно кому то дам новый взгляд. Так что, прям с пылу с жару несу это вам.

Итак, о чем статья то. Я ни в коем случае не обесцениваю труд автора, но я прочел ее краткое содержание примерно так:

Почему нельзя писать код с помощью нейросетей:

1.Вы станете тупым

2.Вас никто не будет уважать

3.Это вообще не дело

Привет, Хабр!

То, что будет происходить ниже – сущий ад. Я буду писать простейшие программы на языке Whitespace (Но не такие простые, как в прошлой статье). Этот язык настолько ненужный, что оригинальный сайт с интерпретатором для этого языка уже давно мертв, все ссылки на оригинальные гайды, соответственно – тоже.

Наверное, в этой форме надо написать выжимку для привлечения внимания? Нуу, мы с головой запрыгнем в язык, состоящий из пробелов, черт побери, что вам еще нужно? А потом этим пробельным кодом отформатируем отрывок из книги «Война и Мир», и он будет прекрасно компилироваться.

Привет, Хабр! Сегодня я расскажу про whitespace.

Whitespace — это уникальный язык программирования, который использует в качестве своего алфавита только непечатные символы: пробелы, табуляцию и новые строки. Этот эзотерический язык был создан Эдвином Брэди и Крисом Моррисом в 2003 и, разумеется, не предназначен для практического применения, существуя как определенный вызов для программистов — мол, попробуй отладить невидимый код.

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

И в этой статье мы рассмотрим базовые принципы этого безумного языка.

Привет, Хабр! Сегодня я расскажу о фиче, которую обнаружил в стандартной библиотеке котлина и реализация которой мне показалась неочевидной, а найти достаточного полного материала в интернете не удалось.

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

Итак, далее в статье:

+Какого черта у null объектов можно вызывать методы?

+Как договориться с компилятором?

+Чем функции-расширения отличаются от родных методов класса?

Начнем.

Привет, хабр! Сегодня я хочу рассказать про свой опыт взаимодействия с языком kotlin.

Представлюсь – я java разработчик, работаю в крупном банке, создаю (и поддерживаю существующие) микросервисы.

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

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

Эта статья, в формате небольших тезисов, нацелена на открытие дискуссии на тему "Test Driven Development" – методологии разработки через тестирование. На моем текущем месте работы существует несколько мнений: начиная от полного принятия и стремления(к tdd), как к идеальному инструменту написания рабочего и лаконичного кода, вплоть до полного отвержения: TDD не работает, убивает время разработчиков, увеличивая при этом time-to-market.

К каждому тезису, которые я выделил, я буду оставлять свой комментарий, стараясь быть объективным и не транслировать какую-либо позицию.

Итак, поехали

Приветствую всех, в данной статье я кратко расскажу и покажу, что такое TDD на очень простом примере.

Итак, представим себя разработчиком в вымышленной ИТ компании, перед которым стоит задача: написать валидатор пользовательских паролей, при этом стараясь следовать принципам TDD.

Начнем разработку нашей программы с ознакомления с требованиями службы безопасности:

Приветствую всех, сегодня я хочу рассказать про одну из самых интересных неразгаданных загадок математики. Гипотеза Коллатца, или же дилемма 3n+1 прославилась благодаря простоте своей формулировки, при этом оставаясь не доказанной уже более 90 лет.

В этом выпуске : обзор самой гипотезы, код-снипеты, кэширование, рекурсия, и много чего еще.

Поехали.

Краткая формулировка, то бишь немного измененная выдержка из википедии Collatz conjecture — Wikipedia Гипотеза Коллатца — Википедия (wikipedia.org):

Берём любое натуральное число n:

1) Если оно чётное, то делим его на 2,

2) Если нечётное, то умножаем на 3 и прибавляем 1.

Над полученным числом выполняем те же самые действия, и так далее.