Dev Easy Notes

Вы уже попробовали deepseek? Я осознал, что за все время существования канала, ни разу не писал про LLM. Ну так вот, если вдруг каким-то чудом вы миновали волну хайпа. Пацаны с Китая зарелизили модель которая, судя по бенчмаркам не уступает флагманской модели ChatGPT.

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

👉 К ней можно обращаться без VPN. Прям повеяло ветерком свободы, как будто опять в Казахстан съездил.
👉 Больше всего меня позабавил режим "DeepThink". Тут ничего нового, этот режим появился еще в модели o1 ChatGPT. Суть в том, что в модель добавляются токены "рассуждения". Однако если в o1 они скрыты в сервисе, то DeepSeek выдает их вместе с ответом.

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

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

Однако когда больше изучаешь историю и причины его создания, все встает на свои места. Изначально язык разрабатывался под конкретные проблемы гугла. Им нужно было сделать инструмент, который бы позволял очень быстро создавать CRUD при этом был простой как сапог и быстрый как алкаш за 5 минут до закрытия КБ.

Почему именно новый язык? С++ слишком сложный, Python слишком медленный, а Java перегруженная, долго стартует и жрет дохрена.

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

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

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

В этом и проявляется вот этот допотопный синтаксис. Он специально сделан излишне упрощенным. Зайдя в любую кодовую базу на Go, ты увидишь одни и те же подходы и конструкции. Ну в частности проверку на ошибку, при вызове почти любой функции. Язык тебе просто не позволит написать код так, как не принято в языке.

Отсюда выходит и поддерживаемость решений. Ты пишешь код, да со страшным синтаксисом что глаза болят, но зато заходишь через 5 лет в этот же код и у тебя вообще никаких удивлений (нуу почти всегда…). Это сильно контрастирует c JS, где ты написал код, а через два месяца оказывается, что уже никто так не пишет и все к херам устарело.

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

Смотришь одного, вроде все норм, ничего не продает и то, что он говорит даже вроде как логично. Затем смотришь другого, уже врача и оказывается, что первый все напутал и все вообще по-другому. Потом смотришь третьего и оказывается что этот врач вообще инфоциган, который продвигает свои БАДы, а первый просто питух. Ядрена, мать…

Ладно, а что если самому попытаться почитать исследования, например взять несколько метаанализов, вроде не должно быть супер сложно. Однако тут тоже не без приколов. Оказывается что исследование исследованию рознь. Есть хорошие с большой выборкой, есть не очень которые обманывают тебя через статистику. Из-за этого можно подтвердить любую точку зрения:

- А кофе полезный? Конечно полезный, 3 чашки в день для сердца вообще отлично…
- А кофе вредный? Конечно вредный, ты че дурачок, ты в себя черную жижу заливаешь, еще и сон потом плохой…

Штош, подумал я, хотя бы в IT нет такой проблемы. Ну тут сложно напиздеть, ведь все проверяется, любой код можно запустить, чтобы проверить что да, вот эта система действительно работает. Потом вспомнил что у нас есть такие вещи как чистый код, охрененная куча абстракций чтобы один и тот же код запускался одинаково, а еще у нас самый популярный язык это JS…

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

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

Недавно мне пришлось повозиться с системой написанной на node.js. Помните я много гадостей писал про Gradle. Что в нем много магии, у него странно работают кеши, что он жрет чудовищно много памяти. Ко мне пришло осознание, что я с жиру бесился. Gradle по сравнению c npm технология будущего. Фронтендеры, объясните мне, вы с этой херней как живете вообще?

Я вношу изменения в код, все собирается, все прекрасно. В определенный момент npm берет и говорит: а дальше я работать не буду! И нихера не помогает, я по гиту вижу, что изменений с последнего успешного запуска нет. Я и кеши чистил, и все папки с билдом удалял, и зависимости пытался скачать заново – вообще похую. Еще и сам npm рот топтал подсказывать что конкретно не так.

Ладно gradle жрет дофига, но он хотя бы работает и говорит что ему не нравится (ну почти всегда)!

Ну что как у вас начался рабочий год? Лично у меня с сообщение от мака: "Братан, помнишь у тебя прога такая была, Docker, ну так вот, больше нет это на самом деле вирус". Обожаю разработку, ничего не трогал, а оно сломалось.

Я сначала думал, что это опять наши безопастники что-то нахуевертили после нового года. У нас давно уже ходили слухи о том, что нужно переходить на аналог под названием Colima.

Название прекрасное, разработчики судя по Github с Негерии, но жалко что не из СНГ, было бы гораздо вайбовее. Представьте аналог докера Colima и еще сделать аналог кубера под названием Gulag c оркестрацией контейтеров медом репрессии.

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

Даже в этом году, я собирался выпустить посты про свои проебы года. Когда же я начал их накидывать, оказалось, что с учетом контекста и объяснения в чем проеб получается несколько длинных лонгридов, которые больше подходят для статьи, чем для постов в канал. Прикиньте, в этом году я даже с проебами года проебался… короче их решил выпустить уже в январе

При этом не знаю как вам, а мне нравится читать про итоги года других. Опыт других людей это всегда интересно. Готов поспорить это одна из главных причин, почему вы меня читаете. Мало вероятно, что я вам тут какие-то истины открываю.

Короче, в этом году я все таки решил их накидать. Итак, погнали, в этом году:

👉 Посетил 9 городов в 5 разных странах. Путешествие года – Будапешт с Руинбарами и гуляшом
👉 2 раза выступал на митапе. Причем несмотря на то, что я мобильный разраб выступал на бэкендовских митапах. Возможно стоит задуматься…
👉 Сериал года – Хильда. Из всех мультсериалов которые я смотрел, он ближе всех к вайбу Гравити Фолз
👉 Игра года – Frostpunk. Про него делал отдельный пост.
👉 Покупка года – ортопедические стельки на заказ. Потрясающая тема, со временем действительно стал ощущать, что нагрузка в спине стала ниже при долгих прогулках и при этом любая обувь автоматически становится удобной. Да, пока другие айтишники покупают тачки и квартиры, я покупаю стельки… дэээ
👉 Софт года – Raycast. Это замена стандартного маковского Spotlight, только на стеройдах. Я через него делаю почти все, даже список МРов смотрю.
👉 Пожал 115 кг, это больше проеб года, чем достижение, тут есть куда рости 😄
👉 За год набрал 500 подписчиков. Это буквально в 2 раза меньше чем в прошлом, но учитывая, что за год я ни одной статьи не написал и делал большие паузы в постах, в целом результат норм. Нагоню в следующем
👉 Проект года – вот тут пусто. На работе я делал прикольные штуки, но прикол в том, что ни одну не успел довести до ума, они все больше прототипы, чем продакшен реди.

Это финальный пост этого года. Всем огромное спасибо, что продолжаете меня читать, всех обнял, приподнял, вы все очень клевые ❤️ С наступающим вас Новым годом! Желаю чтобы в следующем году было чуть легче.

У меня же тут все еще большинство людей мобильные разрабы, вопрос такой возник.

Вы уже себе в приложение снежинки добавили? Если же не добавили, то чем вы весь декабрь занимались?

Cейчас период, когда релизы заморожены, все получили свои новогодние премии и в работе столько же смысла сколько в сюжете хентая. Кто-то проходит advent of code, кто-то уже просто чилит на работе, а я же решил провести небольшой эксперимент.

Я уже упоминал о боте, которого делаю на работе, я расскажу про него подробнее в своих проебах, но сейчас важно что он написан на ktor. Почему я вообще взял ktor? Изначально это был страшно мелкий проект, буквально один запрос. Как мобильный разраб, который последние лет 6 пишет на kotlin я решил, а почему бы и бэк не написать на чистом kotlin?

Да, я уже работал бэкендером на своей первой работе и знал, что Spring крайне удобная вещь. Однако во мне взыграла гордыня, и я подумал что все проблемы связанные с сыростью технологии в ktor я решу своими силами и даже koin мне не помешает. Ну сказано сделано, подробности можете узнать у моего психиатра...

В преддверие праздника, ко мне явился призрак прошлого опыта: а что если, чисто ради прикола, попробовать часть функционала реализовать на Spring Boot? И вот чтобы вам передать мои ощущения, представьте, что вы разработчик, который всю жизнь писал веб сервисы на голом C, и тут вам показали Java.

Большая часть задач, над которыми мне в ktor приходилось что-то придумывать в spring решаются подключением зависимости. Даже код менять не нужно! Я столько времени потратил на подбор либы для конфигурации, а в spring оно из коробки работает. Причем сразу со всем форматами, ему вообще похую.

Правда у этого есть своя цена. Ты теряешь контроль, крайне высокий уровень магии, чтобы отследить откуда что вызывается, нужно прям знать что искать. Уровень магии высокий, но не до уровня магии в gradle, все еще далеко!

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

Да и как тут устоишь, если сама вселенная намекает!

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

Да, справедливо, в целом я немного прихуел, но стоит пояснить. Я последние 2 года работаю в команде инфры: пайплайны, билды, метрики, эмуляторы для тестов вся вот эта фигня. Иногда я даже встречаю название своей позиции: mobile devops. Хотя по идее это не совсем devops, но да похер. По большому счету мне интересно продолжать этим заниматься.

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

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

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

В случае, если я захочу сменить компанию, вероятнее всего я буду собеситься как обычный Android разработчик. Мне на собесе придется отвечать на вот эти ебучие вопросы: "А сколько методов в классе Object?", "Расскажи сколько раз вызывается onMeasure в CustomView", "А как бы ты ускорил RecyclerView?", "А ты знаешь что такое Json?"– господи убейте меня.

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

Я на канале никогда не писал про игры, но про эту не могу не написать, настолько она откликнулась в моей душе. Я уже давно видел рофлы про опилки в суп и детский труд, но не вдавался в подробности откуда это. Итак – frostpunk.

Если вдруг про нее не слышали. Суть сюжета: Температура на всей планете снижается быстрыми темпами, упала до -20 и продолжает уменьшаться. Вы с группой людей отправляетесь на север в поисках убежища. Гениальное решение верно? Да! Ведь именно на севере расположен генератор тепла, вокруг которого вы возводите поселение.

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

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

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

Все это я пишу не просто так. Ведь frospunk очень хорошее олицетворение работы в команде инфры. Ты пытаешься сделать как можно лучше, но люди почти всегда будут чем-то недовольны)

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

Ktor, я взял, потому как он казался легковесным и простым, все на kotlin и корутинах. Для меня как для мобильного разраба бесспорный плюс. Правда в этой простоте и кроется недостаток. Недостаток которому подверженны Compose и корутины в целом. Простые вещи делать страшно просто, а сложные вещи в разы геморнее, чем в том же Spring.

DI завязан на koin, который как вы знаете я очень люблю и уважаю, нет готовых инструментов, чтобы хранить сессии в редис и для авторизации нужно оборачивать функции обработки запросов в другие функции (почти как Compose только для бэка). В Spring такие вещи уже давно решены и делаются одной аннотацией.

Правда в Spring другой прикол, ты заходишь в любой туториал, и тебе говорят, ну вот ебани эту аннотацию и внyтри объекта создай вот такой экземляр класса и оно заведется.

И это блять, вообще не очевидно. Практически все исключительно на уровне документации, ты никак по коду это не отследишь. Там такой уровень магии, что кажется можно было победить темного лорда закидав парочкой примеров из Spring, и никакая бузинная палочка не помогла бы.

Чтобы вы понимали, у нас только что упал кубернетес который находится угадайте где?) Правильно на серверах Яндекса. Это правда так совпало, не то, чтобы я ждал когда все наебнется чтобы выпустить пост. Ну или они возможно так мстят, обидчивые однако...

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

Меня в край уже заебал Яндекс. Это просто немыслимо, меня умудрилось расстроить каждое приложение экосистемы. Думали я только Gradle могу хейтить? Сегодня я сделаю исключение!

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

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

Ты нажимаешь на "оплатить картой яндекс", тебя перекидывают на экран создания карты. Ты ее создаешь, потом пополняешь, пока все хорошо и правильно. Потом ты идешь в корзину и пытаешься выставить оплату картой. Однако при нажатии, тебя отпинывает на страницу карты. После 15 минут попыток, от слова пыток, я нашел что нужно сделать.

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

Ну как вам UX? Правда здорово? Я думал я с ума сойду от ярости! Это же блять ваш банк, ну сука сделайте вы сами еще один запрос и сами добавьте свою же карту! Ну это же абсурд, они не могут двумя командами договорится чтоли?

Увидел недавно комментарий к статье про сравнение MVVM и MVI (прикиньте, их до сих пор пишут), и кое-кто написал следующее:

Есть один метод обработки событий аля handleAction то это MVI, а если несколько разных методов это MVVM

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

Поэтому попробую объяснить… Вот у вас есть ViewModel, вы используете MVVM и решили, сейчас я добавлю единый state и у меня будет MVI. Нет не будет, у вас будет MVVM просто с единым state вместо нескольких полей, вот и все.

Главных отличий MVVM от MVI 2: реактивный подход для обработки событий, и state который меняется последовательно и только в одном месте.
Реактивный подход означает, что вы не просто делаете большой switch и в зависимости от action вызываете те или иные функции. Вы этот action отправляете в очередь, где он уже позже обработается. В этом и проявляется реактивность, мы обрабатываем все поступившие action по очереди, друг за другом, и прикладываем к обработке текущий state, но об этом далее.

Ключевое отличие между MVI и MVVM с единым state – изменение этого самого state в одном конкретном месте последовательно. Если у вас несколько мест где меняется state, то вся идея unidirection data flow идет лесом. Если два метода будут одновременно менять state, то он может оказаться в некосистентном состоянии, нет никаких гарантий. Даже если вы поставите lock и в один момент времени state будет менять только один поток, все равно вы не контролируете порядок, это не реактивный подход. Когда по коду раскидано изменение состояние, ты попробуй отдебажить все это дело, когда у тебя куча асинхронщины.

Вся идея именно в том, что action отправляются в очередь, накладываются на текущий state, генерируется новый state в одном месте и все повторяется заново. Поэтому все чуть сложнее чем просто зафигачить один единый state во ViewModel.

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

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

Смотрите под ноги, дамы и господа, ибо я собираюсь уронить немного мудрости. Когда-то давным-давно я проходил курс по тестированию. Там говорилось о 7 основных принципах тестирования. Один из них называется "Скопление ошибок", который гласит: "Ошибки часто концентрируются в небольшом числе модулей".

Этот принцип немного отдает эзотерикой, если мы обнаружили баг в какой-то фиче, то с очень высокой долей вероятности в этой фиче есть ещё баги. Не очень очевидная идея.

Однако на практике я постоянно на это натыкаюсь, вот сука, почти каждый раз. Ты делаешь какую-то фичу, в ней обнаруживается баг. Ты лезешь его чинить и по пути обнаруживаешь ещё 3 бага, а если не обнаруживаешь, тебе эти 3-4 бага прилетят от QA в ближайшее время. Ну бывало же у вас такое?

Короче, в чём мудрость: если вам прилетел баг на какую-то часть системы, приглядитесь к ней тщательнее, скорее всего, там ещё бага 3-4 рядом.

Недавно на работе возник разговор о Double check locking. Напомню если вдруг забыли. Вот представьте у вас тяжелый объект какой-то, который при создании требует кучу или памяти или времени, и вы не хотите его создавать сразу, а лениво когда понадобится. Мы можем конечно просто взять и вынести его в функцию, и потом вызвать в нужный момент:

private var heavy: HeavyObject? = null

fun get():HeabyObject { 
 if( heavy == null ){
  heavy = HeavyObject()
 }
 return heavy
}

Однако, что если два потока одновременно вызовут эту функцию? Если класс действительно тяжелый, например инициализация LLM это может быть проблемой. Я уже молчу про остальные проблемы с visibility поля и прочими проблемы с многопоточкой. Тоже мне проблема, ну можно же тупо поставить синхронизацию и все, делов то.

private var heavy: HeavyObject? = null

fun get():HeabyObject = synchronized { … }

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

Чтобы решить эту проблему, придумали подход называемый Double check locking, который используется в Dagger кстати. Суть проста, давай захватывать Mutex только если мы видим что объект еще не проинициализирован.

@Volatile
private var heavy: HeavyObject? = null

fun get(): HeavyObject {
    var result: HeavyObject? = heavy
    if (result == null) {
        synchronized(lock) {
            result = heavy
            if (result == null) {
                result = HeavyObject()
                heavy = result
            }
        }
    }
    return result!!
}

Ну понимаете да, сначала чекаем на null, затем захватываем Mutex и еще раз чекаем, ведь кто-то мог захватить Mutex раньше и уже проинициализировать поле. Поэтому и double check.

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

Есть у JVM одна интересная особенность, все static блоки выполняются thread safe, т.е JVM их автоматически синхронизирует потому как важно гарантировать что этот блок вызовется лишь один раз. Еще фишка static блоков в том, что они вызываются только в момент обращения к классу. Поэтому мы можем использовать эту систему, чтобы сделать ленивую инициализацию:

private object FieldHolder {

    val field: HeavyObject = createObject()

    private fun createObject(): HeavyObject = HeavyObject()
}

fun get(): HeavyObject {
    return FieldHolder.field
}

Не особо верится, что тут действительно ленивая инициализация или что оно thread safe. Ради эксперимента попробуйте сами это проверить)

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

Однако в своем коде, если хотите выебнуться на МРе можете такое попробовать. Только потом не плачьте, что с вами на обед не хотят идти. Один дурачок проверял, не будут раскрывать его личность....