Чем отличается Telegram от других популярных мессенджеров? Он — открытый!
Другие мессенджеры тоже имеют API, но почему-то именно телеграм известен как наиболее открытый из самых популярных?

Начнем с того, что у Telegram действительно полностью открытый клиентский
код. К сожалению, мы не видим комиты каждый день прямо на GitHub, но у нас есть код под открытой лицензией. Архитектура Telegram подразумевает, что и Bot и API имеет практически такие же методы — https://core.telegram.org/methods.

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

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

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

Сегодня я хочу рассказать о первой из трёх задач из категории Crypto с прошлогоднего CTF HTB «Cyber Apocalypse». Задачи на криптографию моя отдельная любовь, поскольку позволяют нетрадиционно взглянуть как на привычные криптографические алгоритмы, так и на неудачные попытки их использования. Особенно интересно искать уязвимость в самописных алгоритмах. Последнее наиболее опасно в реальной жизни, поскольку некоторые разработчики уверены, что уж они то смогут как минимум правильно реализовать известный алгоритм, а не тянуть за собой OpenSSL. Некоторые даже стараются написать свой собственный алгоритм и тем самым обеспечить надежную защиту данных! Множество CTF задач разной сложности обычно позволяют быстро развенчать этот миф :-)

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

Основной проблемой единственной инсталляции естественно является надежность. В случае падения сервера нам потребуется некоторое, возможно значительное, время на восстановление. Так восстановление террабайтной базы может занять несколько часов.

Да и исправный бэкап есть не всегда, но об этом мы уже говорили в предыдущей статье.

Привет!

Будем обучать нейросеть распознавать рукописные цифры

Наступил Апокалипсис.

Нет, не стоит бежать запасаться банками с консервами и крышками отечественной бай-колы! Апокалипсис произошёл только в нашей фантазии и с определённой целью — чтобы проверить, а может ли человек, обладающий только книгами по теме и стандартной библиотекой языка, воссоздать инструмент, который будет служить ему верой и правдой?

Так родился учебный проект SicQL, реляционная СУБД, чей символ — сова — это олицетворение силы знаний и мудрости. Олицетворение тех знаний и той мудрости, которые мы получим, создав с нуля то, чем мы пользуемся каждый день, может, не осознавая всей сложности таких инструментов.

Приглашаю присоединиться к увлекательному путешествию!

Этот пост я решил написать, для тех, кто также искал понятный код и рабочий пример, который можно было взять, вставить в гугл колаб(google colab) и сразу начать "играться" с кодом. Но не нашел. Для вас, друзья!

P.S весь код будет в конце.

Импортируем бэкэнд кераса, по началу, мы его использовать не будем, но некоторые функции нам понадобятся.

Представим, что у вас есть некоторая табличка статистики, куда вы периодически скидываете таймстамп последнего "текущего" состояния в паре координат - например, (ID организации, ID сотрудника).

Как больно наступить на грабли в совсем простом, казалось бы, запросе?

Только что натолкнулся на возможность Postgresql, показавшуюся мне забавной. Для кого "баян" — респект вам, я несколько лет работаю с Postgres и до сих пор не натыкался на такую штуку.

select; без указания полей, таблицы и условий возвращает одну строку. Но у этой строки нет полей:

=> select;
--
(1 row)

Для сравнения:

=> select null;
 ?column? 
----------

(1 row)
=> select null where 0=1;
 ?column? 
----------
(0 rows)

А сможем ли мы создать таблицу из такого "пустого" запроса? Таблицу без полей.

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

В кои-то веки, решив написать код для себя любимого, проработал проект, установил окружение, прописал в проекте boost и пошёл писать модули.

Ничто не предвещало беды, но в процессе написания кода было обнаружено, что модуль, который запрашивал у интернета погоду, получал вместо описанного в API json'а следующее: "400 The plain HTTP request was sent to HTTPS port". Уж чем руководствовался разработчик сайта, не перенаправивший запрос без персональных данных, не знаю, но видимо хакеры хотят украсть сведения о погоде в деревне так сильно, что спать и есть не могут.

И тут я сделал манёвр, который стоил мне 50 лет. Точнее, пары бессонных ночей, так как работать тоже надо. Ничтоже сумнящийся, подключил boost::asio::ssl, написал тестовый код, который должен был проверить что теперь есть контакт, но тут моя бровь поднялась вверх в первый раз: проект перестал собираться, потому что в системе не было OpenSSL.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Anatomy of Channels in Go" автора Uday Hiwarale.

Что такое каналы?

Канал — это объект связи, с помощью которого горутины обмениваются данными. Технически это конвейер (или труба), откуда можно считывать или помещать данные. То есть одна горутина может отправить данные в канал, а другая — считать помещенные в этот канал данные.

Создание канала

Go для создания канала предоставляет ключевое слово chan. Канал может передавать данные только одного типа, данные других типов через это канал передавать невозможно.

Находясь в поисках какой-то агрегированной информации о стандартных приёмах, используемых при проектировании кастомных аллокаторов, я обнаружил, что существует достаточное количество статей о том, как аллокаторы работают в C++, каких-то базовых вариантах или наоборот очень специфических версиях, но ничего достаточно общего. Попался только замечательный доклад замечательного Андрея Александреску про неправильную архитектуру std::allocator и собственно базовые концепции построения своего нового самого крутого в мире аллокатора. Эта статья является довольно вольным переводом второй части его выступления с моими небольшими дополнениями. Конечно же, категорически рекомендую посмотреть оригинальный доклад, но, если вы любитель текстовых версий, прошу под кат.

Привет, Хабр! Уже три года живу я в Японии (два провёл в языковой школе, а сейчас эникею в фирме с русским руководством на Хоккайдо) и, несмотря на то что глобально говоря ничего я ещё не добился, рассказы об Японии вызывают у людей живой интерес. Почему бы его не удовлетворить?

И так, начнём с самого животрепещущего вопроса: стоит ли стремиться к трудовой миграции в Японию?

Цель данной статьи:

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