(Нашёл в твиттере тред с очень крутым объяснением работы симметричных шифров. Его написал Colm MacCárthaigh один из основных контрибьюторов Apache. Я спросил разрешение Колма на перевод, он любезно согласился).

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

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

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

Вот простой пример. Допустим, у меня есть строка "Ovaltine" и я хочу её зашифровать. Я мог бы воспользоваться rot13 — очень простым олдскульным шифром Цезаря, который делает хоровод из букв, где a и z держатся за ручки, и заменяет каждую букву другой буквой алфавита, которая находится от заменяемой буквы на расстоянии 13 символов. Таким образом "O" превращается в "B", а "v" становится "i", в итоге "Ovaltine" превращается в "Binygvar". Конечно, это не очень безопасно. Это наивный пример, который очень легко взломать, так как атакующий может выяснить, какая буква встречается чаще всего (обычно в оригинальном тексте это "e") и найти оставшиеся буквы подобным образом.

Приветствую, дорогие друзья!

Хочу поделиться своими рассуждениями на тему логирования и тем к чему они привели.

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

• Log4j
• Java Util Logging
• Commons Logging
• Logback
• Log4j2

Задача производитель/потребитель

Статья рассчитана для новичков, которые недавно начали свое знакомство с миром многопоточноcти на JAVA.

Учимся дебажить с perf — целых 18 страниц про основные подкоманды, фичи и устройство инструмента. Джулия рекомендует; “Я даже использовала его несколько раз для профилирования Ruby программ!”

Уровень сложности — для суперпродвинутого администратора.

Когда нужно отыскать причину сбоя, не имея доступа к исходным кодам. Все логи уже просмотрены, все debug и verbose-ключи включены, а причина проблем так и не обнаружена — используйте perf. Потребуется навык кодинга на языках типа Си.

Математика — это краеугольный камень Data Science. Хотя некоторые теоремы, аксиомы и формулы кажутся слишком абстрактными и далекими от практики, на самом деле без них невозможно по-настоящему глубоко анализировать и систематизировать огромные массивы данных.

Для специалиста Data Science важны следующие направления математики:

• статистика;
• теория вероятностей;
• математический анализ;
• линейная алгебра.

В предыдущей статье «Data Science: книги для начального уровня» специалисты Plarium Krasnodar рекомендовали литературу по программированию на Python, а также по визуализации результатов и machine learning. В этой статье они предлагают подборку материалов и книг по математике, полезных в Data Science.

Крошка-сын к отцу пришел
И спросила кроха
— Что такое хорошо
и что такое плохо

Владимир Маяковский

Эта статья о Spring Data JPA, а именно в подводных граблях, встретившихся на моём пути, ну и конечно же немного о производительности.

Во время изучения иностранных языков много внимания уделяют произношению звуков и слов. Правильное произношение ставят долго — за несколько занятий поймать правильное звучание слов практически невозможно.

Причина очень проста. Звуки и звукообразование в разных языках отличается кардинально.

В японском языке отсутствует звук [l]. И на первых этапах изучения английского языка они заменяют его звуком [r]. Все потому, что в японском звук [r] ударный, а не вибрационный. Во время произношения язык прикасается к нёбу лишь на долю секунды, поэтому на выходе получается что-то среднее между знакомыми нам [р] и [л]. Именно поэтому сложно понять, что имеет в виду японец: «law» или «raw».

Конечно, при целенаправленных тренировках японцы начинают выговаривать звук [l], но крайне малая часть изучающих английский тренирует произношение настолько глубоко.

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

Нередко такие нюансы полностью меняют смысл предложения.

И вместо «I like this beach» («Мне нравится этот пляж») собеседник услышит «I like this bitch» («Мне нравится эта девушка с пониженной социальной ответственностью»).

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

Наверняка, многие слышали, а кто-то встречал на практике, такие слова, как взаимные блокировки(deadlock) и гонки(race condition). Эти понятия относятся к разряду ошибок в использовании concurrency. Если я задам вам вопрос, что такое дедлок, вы с большой вероятностью без доли сомнения начнете рисовать классическую картинку дедлока или его представление в псевдокоде. Что-то вроде этого:



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

Это немного похоже, как это делается строительным блоком: один груз опускаем, а другой, равный по массе, поднимаем. Только для этого вовсе не потребуется троса длиной 380 тысяч км!

Мы больше не контролируем свои домашние каталоги.

В моём собственном 25 обычных файлов и 144 скрытых. В дотфайлах хранятся данные, которые не принадлежат мне: они принадлежат программистам, чьи программы решили захватить моё пространство, предназначенное для хранения моих личных файлов.

Я не могу убрать эти файлы в другое место. Если я попытаюсь их удалить, они появятся снова. Всё, что я могу сделать — это сидеть и знать, что в темноте, за кулисами, они есть. Ожидание в тишине. Некоторые из этих программистов решили дополнительно разместить здесь несколько обычных файлов и каталогов. Они хорошо видны каждый раз, когда я выполняю ls. Понятия не имею, как в мою личную папку попали каталог node_modules, файлы package-lock.json, yarn.lock (я никогда сознательно даже не ставил yarn!), какие-то два странных лог-файла от какой-то Java-программы, явно использующей СУБД H2, и папка Desktop. Последнюю создал Steam, что довольно неудачно, поскольку на моей машине просто нет рабочего стола или какого-то десктопа. Боюсь того дня, когда услышу громкий стук в дверь — и один из этих программистов ворвётся и сообщит, что собирается хранить часть своей мебели посреди моей гостиной, если я не возражаю.

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

Не желал бы я вам попасть ко мне на собеседование года два назад. Я провел их около сотни, и за все время взял может человек четырех. Не знаю почему, но эйчары считали, что это круто. Слава строгого интервьюера шла впереди меня. Знакомые звали меня собеседовать для чужих команд, и даже для чужих компаний, о которых вы слышите каждый день. И везде — не проходил никто.

Приветствую уважаемых хабражителей и Java-программистов!
Cтатья посвящена подготовке к сдаче экзамена Oracle Java SE7 Professional с кодовым номером 1Z0-804. Про это на Хабре уже было написано множество постов (например здесь, здесь, тут, здесь, здесь, тут, тут, и вот тут), поэтому постараюсь не повторяться и дополнить заметками о том что наиболее часто встречалось, важными нюансами, которые на мой взгляд были пропущены или недостаточно хорошо освещены в указанных статьях, и вообще в общедоступной литературе (сразу отмечу, что материал не претендует на полноту, здесь я лишь старался обозначить каверзные вопросы с экзамена и лаконично изложить некоторые сложные вещи). Так же поделюсь своими соображениями насчет того, по каким материалам лучше готовиться. С первого раза экзамен сдать не получилось, поэтому начал сохранять для себя различные заметки, где записывал всё что мне казалось сложным или трудно-запоминаемым. Которыми теперь и решил с вами поделится. Заранее прошу проявить понимание, если вы вдруг заметите ошибку, недочёт или очепятку — пишите в комментарии.

Хоть от многопоточности и библиотек, которые её поддерживают, отказываются немногие Java-программисты, но тех, кто нашёл время изучить вопрос в глубину ещё меньше. Вместо этого мы узнаём о потоках только столько, сколько нам требуется для конкретной задачи, добавляя новые приёмы в свой инструментарий лишь тогда, когда это необходимо. Так можно создавать и запускать достойные приложения, но можно делать и лучше. Понимание особенностей компилятора и виртуальной машины Java поможет вам писать более эффективный, производительный код.

В этом выпуске серии «5 вещей …», я представлю некоторые из тонких аспектов многопоточного программирования, в том числе synchronized-методы, volatile переменные и атомарные классы. Речь пойдет в особенности о том, как некоторые из этих конструкций взаимодействуют с JVM и Java-компилятором, и как различные взаимодействия могут повлиять на производительность приложений.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

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

Это новая статья из разбора задач с собеседований в Google. Когда я там работал, то предлагал кандидатам такие задачи. Потом произошла утечка, и их запретили. Но у медали есть обратная сторона: теперь я могу свободно объяснить решение.

### Часть 1. Золотое «Ку»

Лет в шесть мне попался в руки дедовский справочник^[50] по грузовым автомобилям середины 20-го века. Добротный, напечатанный на гладкой плотной бумаге раритет. Единственное, что вообще осталось на память от деда после распада страны, войн и переездов.



В справочнике содержалось множество интересных ТТХ, так что слово «грузоподъёмность» стало мне знакомо с раннего детства. И когда отец на прогулке упомянул, что любой грузовик весит столько же, сколько увозит сам, я это запомнил. Запомнил и, много позже, заинтересовался.

Отец был прав. Для грузовиков 60-х годов это правило выполняется с довольно удивительной точностью:

В Интернете уже немало копий сломано по поводу того, отличаются ли с точки зрения пользователя экраны электронных книг (изготовленные по технологии E Ink) от экранов планшетов и смартфонов (по технологиям LCD и OLED), или же никакого существенного отличия нет? Свет – он и в Африке свет?!

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

Сначала – расшифровка обозначений LCD, OLED и E Ink.
LCD — это Liquid Crystal Display, дисплей на основе жидких кристаллов. У них есть разновидности: TN, IPS, VA и др.

OLED – это дисплей на основе светоизлучающих органических диодов, Organic Light-Emitting Diode. У них тоже есть разновидности: AMOLED и Super AMOLED.

E Ink (Electronic Ink) – это дисплей на основе «электронных чернил» («электронной бумаги»), где изображение формируется микроскопическими частицами пигмента. Собственно, так же оно образуется и на «настоящей» бумаге, только измениться потом не может.

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


Пост подготовлен совместно с dlinyj, который выступил в качестве рецензента и консультанта в вопросах физики электричества и охраны труда, а также соавтора раздела “Что убивает ток или напряжение?”. Под катом я подробно описал механизмы получения электротравмы, медицинские последствия, а также проанализировал несколько трагических случаев, связанных с необычными электротравмами. При подготовке материала использован мой собственный медицинский опыт, факты, известные из СМИ, а также доступную в сети литературу и документы (фото поражений, содержащиеся в статье, некоторые читатели могут счесть шокирующими и неприемлемыми).

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

Те, кто давно занимается поисковой оптимизацией, хорошо знают об операторах расширенного поиска Google. Например, почти все знают об операторе site:, который ограничивает поисковую выдачу одним сайтом.

Большинство операторов легко запомнить, это короткие команды. Но уметь эффективно их использовать — совсем другая история. Многие специалисты знают основы, но немногие по-настоящему овладели этими командами.

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