​​Strange Public API

Как-то пришлось реализовать распознавание пола по имени и наткнулся на следующие сервисы:
https://genderize.io/ - определяет пол по имени
https://nationalize.io/ - определяет национальность по имени
https://agify.io - определяет возраст по имени

Как работают первые два я еще могу понять, но осознать третий - никак.
Если есть идеи как определить возраст по имени то го в комменты к этому посту)

​​TamperMonkey

userscript manager

tampermonkey - очень крутой браузерный extension для того что хранить и запускать javascript-ы в браузере.
Доступен для Chrome, Edge, Safari, Opera, Firefox.

Из того что пока выделил для себя я:
- Возможность ранить и сохранять скрипты по желанию (гораздо удобнее чем Chrome Snippets)
- Возможность настраивать скрипты для автоматического запуска на урлах
Обязательно попробуйте если любите покапаться в коде страницы и умеете в js.

​​Rick and Morty in terminal

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

​​Тренды Github

За последние полгода, вижу рост популярности всяких spy инструментов в трендах github-a.
Начиная от поиска человека по фото в соцсети, до программ которые в реальном времени вырезают человека с видеоряда.
Популярность набирают даже либы которые топорно ищут юзернейм в соцсетях, вроде sherlock.
Спрос рождает предложение ¯\_(ツ)_/¯.

​​Copy request as a cURL

У Chrome Developer Tools есть одна очень маленькая но безумено полезная фича.
Правым кликом на запрос можно скопироваь его в виде cURL со всеми cookies, headers итд.
А потом с помощью curltrill можно преобразовать в код-семпл на большинство ЯП.
Очень удобно когда приходится работать с сайтами, которые не отдают респонс без пары нужных хедеров.

​​Привет
Готовлю для вас крутой материал про git.
Разберем все что находиться внутри, как все работает.
Что такое референсы, метки, head, индексы, бранчи с технической точки зрения.
Думаю на днях закончу собирать все в кучу и начнем.

​​DeepGit: Plumbing и Porcelain - введение.

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

Изначально git был больше инструментом для создания VCS чем непосредственно VCS.
Знакомый нам git в виде git add, git commit, git merge итд это "высокоуровневые" врапперы над низкоуровневыми командами вроде git update-index, git hash-object, git cat-file и других.

Вся "магия" гита спрятана внутри папки .git и представляет собой своего рода файловую систему с файлами и папками.

Что у нас появляется внутри папки .git после создания:

 tree -a
.
└── .git
    ├── branches
    ├── config
    ├── description
    ├── HEAD
    ├── hooks
    │   ├── applypatch-msg.sample
    │   ├── commit-msg.sample
    │   ├── post-update.sample
    │   ├── pre-applypatch.sample
    │   ├── pre-commit.sample
    │   ├── prepare-commit-msg.sample
    │   ├── pre-push.sample
    │   ├── pre-rebase.sample
    │   └── update.sample
    ├── info
    │   └── exclude
    ├── objects
    │   ├── info
    │   └── pack
    └── refs
        ├── heads
        └── tags

Упустим пока все файлы кроме основных: HEAD, index, objects, refs.

refs - папка содержит ссылки на обьекты коммитов.
objects - папка git-обьектов
index - содержимое индекса
HEAD - содержит ссылку на актуальное состояние.

Остальные папки вроде hooks которае содержит "тригеры" на на различные действия или папка config с доп настройками для этой репы не являются частью "двигателя" гит.

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

Еще до того, как это стало мейнстримом 😎@dev_daily

​​IdeaVim

Не люблю когда IDE начинают "косить" друг под друга.
Есть весьма суверенный редактор - вим, зачем его интегрировать в jetbrains?
Или зачем из vim делать jetbrains обвешивая его сотнями функциональных расширений.

Есть ли тут люди которые пользуются этим или подобными расширениями?

P.S. Последние пару дней был очень загружен и не успел дописать вторую часть про .git.
Думаю следующая статья уже выйдет о нем. Если пропустили первую, то вот ссылка.

​​DeepGit: Hashing and Cating. Понимаем файловую систему.

Ч1

Как я говорил ранее, Git это файловая система основой которой являются файлы типа tree, commit, blob.
Подробнее о типах файлов у меня вышла статья на DevQuiz.
Рекомендую прочесть ее и вернуться сюда.

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

Чтобы добавить файл в git есть техническая команда git hash-object -w filename.txt она делает blob файл с вашими данными и сохраняет себе в objects.

После этого git status все еще будет пуст, так как индекса еще нет, но git уже сохранил себе версию этого файла.
Именно эта команда лежит в основе гита, это такой себе "save" ваших данных.

Например вы сделали

 echo "first version" >  new_file.txt
 git hash-object -w new_file.txt

У вас появляется файл new_file.txt с текстом first version и появляется файл de8d69c9026be2a49f540fda12f3e755a33e6c в папке 22 с таким же текстом.

Следом мы делаем

 echo "second version" > new_file.txt
 git hash-object -w new_file.txt

У нас появляется доп файл 7ac37bb280ccd34b350a59ba440614d9106e41 в папке ad с текстом second version

Теперь с помощью git cat-file -p 22de8d69c9026be2a49f540fda12f3e755a33e6c > new_file.txt можно переключиться на старую версию.

И все это происходит до того как вы сделали git add.
Все еще с пустым индексом.

​​DeepGit: Blobs

Ч1, Ч2

blob (binary large object) - файл который содержит полный текст файла.
Что примечательно, для git-a не имеет значение в каком именно файле были сделаны изменения.

Простыми словами:
Если мы созданим новый файл с текстом "some text" ,
и этот же текст добавим в новый другой файл
и сделаем git hash-object то получим всего один новый blob файл.


И если мы сделаем git write-tree то увидим в файле дерева имя этого blob-a накатываемого на оба файла.

 100644 blob <hash>    first_file.txt
 100644 blob <hash>    second_file.txt

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

P.P.S У нас появился чат, нажмите кнопку Discuss(Обсудить) справа внизу. Буду всем рад.

​​Разоблачаем "домашних хакеров"

На одном из "хакерских" каналов увидел статью про взлом bluetooth колонок. Вот копия статьи.
Короткий пересказ статьи:
- Находим девайсы по близости;
- Получаем их MAC адреса;
- Пушим на девайс тысячу запросов ping или connect что-бы колонка отвалилась;
- Радуемся.

Звучит прекрасно, если ты не знаешь как работает bluetooth.

Во-первых, у bluetooth-спикеров есть состояние "discoverable", когда к аудиодевайсу никто не подключен его действительно можно обнаружить сканерами, получить MAC адрес и даже подключиться. Но, если у девайса уже есть активное подключение, то ничего из вышеперечисленного вы сделать не сможете.

Даже зная заранее MAC адрес девайса, и начав отправлять ему запросы, все они будут отклонены.
Единственное, что у вас теоретически может получиться, это имея MAC адрес девайса понять находиться ли он в зоне видимости.
По этому поводу есть хак трехлетней давности на stackoverflow.

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

P.S. Как Вам такой формат публикаций? Если интересно, то могу иногда выпускать подобные "разоблачения".

​​DeepGit: Hashing names

Ч1, Ч2, Ч3

Что-бы закончить с blob-aми , деревьями и коммитами надо разобраться как git генерирует имена файлам и как хранит все версии всех файлов.

Название git файла определяется следующим образом:

 tree #{text.lenght}\0

Общее правило: тип файла => решетка => длина текста => нулевой байт.

Это наш хедер.

Что-бы получить название файла:
Добавляем к хедеру текст файла и берем SHA1 сумму от результата.

Текст файла git сжимает через zlib.

Как это можно реализовать на python:

 [1]: import hashlib
In [2]: from hashlib import sha1
In [3]: sha = hashlib.sha1()
In [4]: line = "developer tools test line"
In [5]: header = f"blob {line.__len__()}\0"
In [6]: content = (header + line).encode()
In [7]: sha.update(content)
In [8]: sha.hexdigest()
Out[8]: '7f0571380d1f5e2a2fb13bb25eeefe5761895e7a'
In [9]: import zlib
In [10]: zlib.compress(content)

Первые два символа из 7f0571380d1f5e2a2fb13bb25eeefe5761895e7a пойдут как название директории, а остальные в название файла.

Резюме: Внутри git нет никакой магии, все данные весьма просто храняться и так-же просто используются.

Напоминаю Вам, что у нас есть чат: https://hottg.com/developer_tools_chat , непонимаю почему вас там так мало :)

​​DeepGit: Экзамен

Мы разобрались с оновными основами основ в git:
Как выглядит директория git-a
Какие есть типы данных в git
Как git сохраняет версии и накатывает их
Что такое blob и как он хранит данные
Как собирается hash и архивируется текст

Давайте теперь глянем как это все собрать воедино:

- создадим репозиторий;
- добавим новый файл с текстом;
- коммит;
- добавим новый файл с другим текстом и изменения в первом файле;
- коммит.

C помощью привычного git-a выглядит следующим образом:

 git init
 echo "text" >>1.txt
 git add 1.txt
 git commit -m "commit"
 echo "text1" >> 1.txt 
 echo "text" >> 2.txt
 git add .
 git commit -m "commit 2"

Теперь как это можно сделать с помощью низкоуровневых команд git:

 git init
 echo "text" >> 1.txt
 git hash-object -w 1.txt
 git update-index --add 1.txt
 git write-tree
 echo "commit" | git commit-tree <tree>
 echo "text1" >> 1.txt 
 echo "text" >> 2.txt 
 git hash-object -w 1.txt 
 git hash-object -w 2.txt
 git update-index --add 2.txt
 git update-index 1.txt
 git write-tree
 echo "commit 2" | git commit-tree <tree> -p <pcommit>

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

Завтра или послезавтра на @dev_quiz опубликую пару тестов по разобраному тут материалу с git-ом.
Следующее, что мы будем разбирать в git будут референсы и все, что с ними связано.

Напоминаю, если у вас остались вопросы или пожелания, можно их обсудить в нашем чате: @developer_tools_chat

​​Привет)

Меня спрашивают какие инструменты и технологии я использую регулярно.

Starter Pack:

Terminator - мой первий эмулятор для работы в нескольких терминалах в одном окне.
Tmux - на него я перешел с terminator и пользую по сей день. Считаю его одним из лучших решений для работы с несколькими терминалами.
Перейдя на tmux необходимость в terminator отпала, но у меня там уже были настроены цветовые схемы, шрифты, потому решил оставить его.
Zsh - я просто начал использовать его весто bash.
autojump для быстрого перемещения между папками.
Ну и fzf для поиска, истории, kill.

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

P.S. Код я пишу в JetBrains софте.
Много раз я пробовал безуспешно перейти на NVim.

​​explainshell

Очень удобный сервис, который разбирает шелл команды.
Я не особо хорошо умею в bash скриптинг и зачастую пользую готовые решения вместо сложных команд.
Но периодически на форумах ищу решения и натыкаюсь на огромную шелл команду которая делает что-то непонятное.
На explainshell.com можно разобрать что именно происходит в команде.
Оч удобно.

​​Vim in Cube

Я периодически пробую перейти на vim.
Просматривая разные его вариации натыкаюсь на удачные вроде nvim, onivim.
Но недавно я наткнулся на Vim Cube.
Мне кажется это вершина. Лучше уже не будет.
Если я и уйду когда-то от Jetbrains то только к Vim Cube.

​​regex101

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