Экстраполяция IT

Обожаю такие вещи. Когда есть что-то сложное, что в среде экспертов объясняется формулами, терминами и концепциями, но можно показать вот такую картинку и спросить «Теперь тебе понятно что такое "нормальное распределение"?»

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

Пару месяцев назад удалось купить прибор ночного видения для подразделения пограничников «Шквал». Вот, показывают как он работает и говорят, что тяжело переоценить его полезность. Просят ещё. Не хватает приблизительно тыщ 70. Спасибо за помощь. https://send.monobank.ua/jar/8zAeCbuMw1

Не уверен, что хочу разбираться что тут происходит, но это React 19 вместе с Typescript 6.

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

Господа рубисты и рельсовики-зайтейники. А накидайте-ка мне, пожалуйста, в комментарии или в личные сообщения блоги, которые вы читаете по теме. И ещё репозитории, за которыми обязан следить каждый уважающий себя рубист. Может, какая рассылка есть ещё? Тоже подойдёт. Очевидные и само собой разумеющиеся тоже кидайте, не стесняйтесь. Мы тут штуку одну делаем, надеюсь, в итоге будет полезна всем. Спасибо.

Хлопці передають нам вітання ❤️. Дякую усім, хто зі мною допомагає цим бравим козакам. А хто ще не допомагає, але дуже хоче, то у опису до каналу є посилання на банку. Слава Україні.

Главная ошибка в разговорах о повышении зарплаты — это расхваливание своих бывших заслуг. Логика работодателя вполне простая: сотрудник делает своё дело, в конце месяца получает за это деньги. И так каждый месяц. Договорённость о зарплате — это обещание заплатить столько-то денег, когда сотрудник сделает столько-то вот такой вот работы. Это не делёж награбленного на приратском судне, где сильные и авторитетные пираты получат больше, это не признание в любви к сотруднику, где покупают бриллианты «если ты меня любишь». Это всего лишь договорённость об обмене труда на деньги. Из этого естественным образом вытекает очень простое следствие. Работодатель согласен заплатить в следующих месяцах больше, если это выгоднее, чем искать нового сотрудника. Конечно, учитывая все риски долго его искать, найти не того, какое-то время вводить новичка в курс дела. Скажем, зарплата абстрактного сотрудника $100 и он хочет 10% повышения. Работодатель знает, что найти замену можно за месяц и еще месяц уйдет, чтобы ввести в курс дела нового сотрудника. Получается, уволить того, кто есть, будет стоить $200, а повысить ему зарплату будет стоить $120 в год. Руководству, выгоднее повысить зарплату, чем лишиться имеющегося сотрудника. Конечно же, в этой очень простой формуле куча неучтённых факторов, но речь сейчас не о способе рассчитать повышение зарплаты, а об акцентах. Прошлые заслуги — дело прошлых зарплат, а не будущих. Как вывод, при любых разговорах о повышении зарплат или увеличении ответстветнности, речь должна идти только о том, что будет. Конечно, в пример можно приводить то, что было раньше, но только лишь в качестве доказательств, что в будущем будет ещё лучше. Экстраполируйте, короче.

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

Here is my prompt to the GPT3.5 which should generate a structured data in the response. Can you improve that?

{{{PROMPT_HERE}}}

Запросы становятся куда лучше и данные правильнее. И да, в начале «Гопота» мне прям переписывал запросы как бы с нуля, а сейчас вот выдаёт вот такое:

Your prompt is already detailed and clear, but there's always room for some improvement. Here's a refined version:

{{{RESPONSE}}}

Но самое интересное начинается вот только тут. Чтобы понять что же он улучшил и почему, например, мой вариант «Strive to summarize» хуже его чем «Summarize effectively» нужно опять же спросить.

Why the sentence from your prompt "{{part _of_the_prompt}}." is better than my option "{{part _of_the_prompt}}."?

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

Ребята, которым мы помогаем, передают привет и немного сувенирных шевронов для тех, кто регулярно помогает. Шевроны я уже почти всем отправил почтой. Героям слава.

Опишу штуку, от которой я сильно прусь и которая была нами реализована. В рельсах почти во всех таблицах в базе есть два поля updated_at и created_at с соответствующими значениями. Поля полезные, информативные. Однажды я задался целью держать эти поля актуальными, ну там бизнес-логика такого требовала. Чтобы когда создавался новый коментарий у задачи, чтобы updated_at поле обновлялось текущей датой. Вроде бы, задача для рельсовика вообще плёвая, toch: true дописал в нужном месте и делов-то. Потом началось протекание абстракций. Сначала захотелось рекурсивного обновления. Чтобы у таблицы-дедушки обновлялось поле, если внук создаётся. Такой вот рекурсивный touch: true, который вообще-то так и работает. Во-вторых, промежуточные (torugh) таблицы игнорируются фреймворком. Ну вот есть у тебя companies, projects, comments и ты создаёшь companies.comments.create и хотелось бы, чтобы и у соответствующего и проекта и компании updated_at обновлялся, но нет. Ещё каждое обновление updatedat в каждой таблице — это отдельный запрос. В общем, фигня, как всегда. И мы тогда добавили две вещи. 1. Значение по-умолчанию в таблице `createdat поставили в CURRENTTIMESTAMP` 2. Триггер таблицам, которые по всем foreignkey проходятся и там UPDATE updated_at делают соовтетсвующим записям в соседних таблицах. Получилась красота неимоверная. Теперь никаких touch: true, а все записи в базе всегда в актуальных состояниях даже когда данные прямым sql-запросом обновляются.

Читая ваши варианты использования ИИ в работе, вспоминается классика. «Пап, а если ИИ будет делать за тебя половину работы, значит ты будешь работать в два раза меньше? Да, пап? Почему ты плачешь, папа?»

«Кобзар» із віршем «мені сімнадцятий минало, я пас телята за селом» була опублікована, коли Тарасу Григоровичу було 23 роки. Столітня війна тривала 116 років. У «Пташиному молоці» немає молока птахів, а у крабових паличках немає мʼяса крабів. На такі чи подібні цим питання не можна відповісти без двох властивостей ШІ: контексту та додаткових знань. Шо ви як маленькі, їй-богу.

Так, кажется, уже вообще все используют gpt не только, чтобы быстро узнать в каком возрасте Тарас Григорьевич «пас телята за селом», сгенерировать кусочек кода или узнать сколько лет длилась столетняя война. Есть какие-нибудь удачные попытки использовать gpt на корпоративном уровне? Кто-то уже успел встроить его в бизнес-процессы? Не стесняйтесь, делитесь. Если уж сильно стесняетесь разболтать корпоративную тайну, разбалтывайте в личку мне.

Один из самых показательных и любимых «усложнений» в коде — это минимизация вызова методов на классе. Нет, не вообще вызовов, а тех, которые возвращают данные. Например, вместо того, чтобы на уровне контроллера написать Project.find(params[:id]) у меня появляется конструкция current_user.available_projects.find(params[:id]), где available_projects будет методом в классе User с приблизительно следующей реализацией:

def available_projects
  Project.all
end

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

Есть у меня манера такая, из-за которой я постоянно забочусь о будущем гипотетическом вертикальном масштабировании приложения ещё на этапе git init. Буквально везде переживаю, чтобы можно было расширить, засунуть и скейлить новую связь, сделать из отношений один-к-одному отношения многие-ко-многим, всунуть мультипрофили, переключение контекстов и всякое такое. Прям со старта, когда нужно просто добавить одну табличку в базу и модельку создать, у меня на ровном месте появляются company_id, author_id и вот это вот всё такое подобное. С точки зрения энтерпрайза это, наверное, неплохо, но вот в стартапном подходе это сильно мешает ускорится и сделать релиз уже к вечеру. И что с этим делать и нужно ли вообще с этим что-то делать я совершенно не представляю. С одной стороны это сильно тормозит прототипирование. С другой — прототип легко и без дополнительных костылей разрастается в энтерпрайз. В общем, буриданова дилемма никак не иначе.

«Навчайся за донат» — проєкт на підтримку ЗСУ від громадської організації Демократична Сокира! В межах ініціативи слухачі опановують професію DevOps-інженера в обмін на донати війську. 20 травня стартує навчання третього потоку онлайн-курсу, який викладає технічний директор і співзасновник Tucha Володимир Мельник. Під час практичних занять учасники дізнаються, як працювати з Docker, Kubernetes, Helm, GitLab, Ansible та іншими додатковими сервісами, які можна розгортати в кластерах Kubernetes. Загалом курс передбачає не менше 15 вебінарів у Zoom, кожен з яких триває щонайменше 2 години. Докладна програма та деталі проведення курсу — за посиланням. За кожну лекцію слухачі переказують 30.00 USD на рахунок фонду, які йдуть на закупівлю амуніції, військової форми, техніки, засобів тактичної медицини та іншого необхідного приладдя. Наразі завдяки проведенню DevOps-курсів зокрема зібрано понад 1 200 000 грн на потреби війська: авто для підрозділу ППО, квадрокоптери, прилади нічного бачення, портативні зарядні станції, спальники, тактичні рукавиці, купа засобів тактичної медицини тощо. Запрошуємо стати слухачами нового потоку всіх, хто бажає розвиватися у DevOps-галузі та зробити свій внесок у наближення перемоги! Щоб приєднатися, заповніть невеличку анкету. #волонтерство на правах реклами.

Есть очень хороший косвенный признак масштаба компании, с которой вы общаетесь. Ну вот приходит вам емейл с почтового ящика [email protected]. Сразу видно, что это — маленькая компания, скорее всего уровня стартапа, даже если содержимое письма говорит об обратном. Дело в том, что при при определённом пороге красивые короткие имена заканчиваются и любое правило коротких имён перестаёт действовать. Я знаком с правилами выбора емейлов в компании по никнеймам, по первым буквам имени и фамилии, только по именам и вообще хаотические правила «какой емейл хочешь такой и заведём». Но все эти правила нарушаются при первом же дублировании. Можно, конечно, сопротивлятся до последнего и добавлять букву второго имени и придумывать новые псевдонимы, но рано или поздно емейлы приходят к универсальному стандарту имя.фамилия@exampe.com, а вон то старьё в виде никнеймов и аббревиатур становится алиасами, которыми лучше не пользоваться. Следующая стадия размера компании — обезличенные емейлы, вроде [email protected] или [email protected]. Там тяжело сказать о размере, но от таких емейлов тоже рано или поздно отказываются в качестве исходящей почты и оставляют только в качестве входящей рассылки.

Попробую публично апеллировать Вове Рожкову и его мысли, что названия фундаментальных штук, вроде микросервисов должны быть максимально понятными по содержанию и не нужно придумывать красивых новых слов для всего подряд. Вова называет такие названия «кринжовыми» и избегает их. Безусловно, название должно отражать суть происходящего, это даже не обсуждается. А придумывать новые слова или новые значения нужно для тех штук, которым нет удобного слова или словосочетания. Например, был себе джаваскрипт такой, существовал, а потом у него появилась особого вида функция, которая асинхронно вызывает другую функцию. Ну есть же термин «функция высшего порядка» там, а у нас тут асинхронный вызов функций. Ну назови ты её «async higher-order function» и всё. Зачем же придумывать для неё отдельное слово «Promise»? Но вот придумали, потому что этот вот промис планировался, как особого вида функция и что это не просто «async higher-order function». А дело в том, что так в человеческих языках и придумываются новые слова и новые значения. Для тех штук, которые долго объяснять по сути и длинно читать по составу люди находят красивые и лаконичные слова, чтобы быстро коммуницировать друг с другом. Конечно, важно не придумывать искусственный язык, чтобы заставлять на нём всех общаться, а идти на поводу у естесственного общения и придумывать названия для папочек и репозиториев такие, какими их называют люди между собой. В одном проекте мы назвали сущность, которую пользователь через интерфейс запрашивал у менеджера и заполнял поля «Request». Вроде бы логично, пока не оказалось, что в фреймворке был баг и в некоторых случаях глобально доступная переменная внутри языка шаблонов «request» возвращала экземпляр http-запроса, а не нашу локальную переменную request = Request.find(params[:id]). Пришлось придумывать синоним Demand и менять внутреннюю терминологию. Для душнил уточню, что в интерфейсе для пользователя, конечно же, остался request 🙂 С тех пор я стараюсь избегать общих терминов и слов, которые можно было бы трактовать двояко. В другом проекте было несколько ролей пользователя со своими интерфейсами. Ну, скажем, ORM-модели назывались стандартно User, Project и Company, а вот неймспейсы для каждого пользователя тогдашний архитектор назвал Egg, Chicken и Ranch, подразумевая, что в Ranch можно создать себе Chicken, а в курице — яйцо. Преимущество перед UserApp было огромным, потому как поиск файлов с префиксом egg прятал то, чего не хотелось видеть. Да и интуитивно понятно что из себя представляло каждое из приложений. А третий пример про особого вида микросервисы в ещё одном проекте, где мы себе придумали такие микросервисы, которых и пристрелить было не жалко и запускать можно было бы когда угодно. Ну, умирали они часто, ну и хрен бы с ними. Там и другие микросервисы были разные, важные и ответственные, но вот эти вот были на особом счету и с особой структурой работы с ними. Назвали мы их сначала «быстродохнущими микросервисами», а потом кто-то назвал их «Леммингами» и оно прижилось так хорошо, что стало префиксом в названии каждого такого микросервиса. Ну, там «lemmingautosubscription» или «lemmingstoryhistory». Короче, нельзя придумывать названия просто так. Этимология любого названия обязательно должна быть.

Небольшой волонтёрский апдейт. Две отремонтированные машины (вторую без номеров или лиц в галерее я не смог найти, сорян) и ещё один купленный Пежо уже у ребят. Пежо уже успел совсем чуть-чуть побывать в бою и уже снова ремонтируется, но это не беда, — отремонтируем и эту. А ещё удалось приобрести и отправить подразделению пограничной службы «Шквал» прибор ночного видения для водителя. А ребята в ответ передали благодарность и привет всем причастным. Там все к чему-то активно готовится, ума не приложу к чему конкретно, даже идей никаких нет. Ну и пусть готовятся, наше дело помогать им со всех ног и рук, а не спрашивать «к чему» или «когда уже», правда ведь? 🫡

А вот и экологи подтянулись. ИИ — это не только потеря рабочих мест, паника на биржах, новые фантастические романы и вот это вот всё, что мы любим, а ещё и потеря пресной воды. Исследователи внезапно (нет) обнародовали сенсационные данные, что обучение нейросетей оказывается потребляет не только энергию. Это всё и охлаждать надо или зачем там ещё вода нужна в датацентрах. Короче 700 тысяч литров пресной воды нужно, чтобы обучить GPT-3, а короткое общение пользователя с ИИ равносильно выливанию на землю бутылки пресной воды. Что с этим делать — непонятно. Просто how dare you, я так понимаю. Интересно, есть ли исследование сколько воды выпивают сервера, которые индексируют страницы интернета гуглом. https://arxiv.org/abs/2304.03271

Внезапное (нет) и ультимативное применение недочеловеческогол услужливого разума. Когда нужно поверхностно разобраться в отраслях и технологиях, где дупля не отбиваешь. Или когда отвечать на каверзные вопросы продавцов нужно, вроде «Вам комплектация UTR GEN7.1 или MGF-12V матрицей?». Попробуйте гуглом так вот ответ найти. Пару часов гугления и углубления в экспертные форумы обеспечено. Только вот продавцы будут крайне странно смотреть, когда после каждого их вопроса по пять минут в телефон нужно будет втыкать.

​​Когда-то давным давно, лет тринадцать назад, учавствовал я, значится в одном проекте, который достался нам от индусов, нужно было прикрутить маааленькую фичу, ну то есть переписать всё. В общем, ничего необычного. Но мы тогда в коде, в классе User обнаружили метод dr_smith?, который проверял айди пользователя на то, равен ли он 63 или не равен. Ну, вот так вот буквально.

def dr_smith?
  self.id == 63
end

Нам тогда это подняло настроение на добрых пол дня и мы такие ходили кругами и рассказывали какие же эти индусы недотёпы и как же они не умеют писать код. А вот тут оказывается, что это не просто так надо, а ещё и так эффективно. Что фигачишь if просто в нужном месте и деплоишь поскорее в надежде, что этот кусочек не разростётся во что-то огромное и неповоротливое. Короче, пишем в коде authoriselon и гордимся.

Короче, общаюсь я со своим напарником, пишем, значится, код вдвоём. Всё, вроде отлично. Пишем, исправляем друг друга, спорим по мелочам и смеёмся над шутками и вообще весело проводим время. И вдруг — БАЦ! Мой собеседник перешёл на совершенно другую тему, начал что-то про джаваскрипт писать, виджеты генерировать и окна двигать. Оказывается, как потом признался мне мой визави, этот ответ предназначался совсем не мне, а кому-то другому. Как в том отзыве на али, хотел бы я посмотреть на того, кто заказывал пылесос, а ему пришло это.

Короче, мальчики и девочки, коллективная фаза отрицания прошла. Стадию гнева, по всей видимости или пропустили или если плакать в туалете, то не считается. Теперь это всё сменилась фазой торга. Кучу известных людей подписалось под коллективным письмом, призывающим остановить разработку ИИ, чтобы не угнетать бедненьких кожаных мешков и их естественными желаниями работать джунами и миддлами. Естественно, никто из openai письмо не подписал, а вот всем остальным очень и очень страшно. А помните те времена, когда в интернете искали всё с помощью Yahoo? Пришедший Гугл очень быстро вогнал последний гвоздь в крышку этого самого Яхуу без всяких сентиментов. Сейчас мы находимся где-то приблизительно в такой же ситуации, только ступенью выше. https://futureoflife.org/open-letter/pause-giant-ai-experiments/

Збір на 4 🌚 ударні багаторазові FPV дрони з тепловізором Мій товариш Віталій Ратушний збирає кошти на чергову серію топових ударних дронів ☠️Death From Above🦅. Ми вже успішно провели два збори, було зроблено величезну RnD роботу, а характеристики дронів значно покращені. Увага! Це НЕ камікадзе, після виконання завдання дрони повертаються на базу🕊 На відео — робота попередніх версій. Працює підрозділ пілотів 45-го ОСБ💪 Влучання не в танк, а поряд з ним навмисне, щоб уразити піхоту. Характеристики топові: дальність 8 км, 3 кг корисного навантаження, низький шум, 4к відео. 😎А в цій партії додаємо у комплектацію тепловізор! Це дозволить літати вночі 🌚 та підвищить живучість дронів💀 Вартість одиниці: 1800$. Всього збираємо 7200$. upd: зняли частину грошей щоб оплатити комплектуючі. 👉Банка: https://send.monobank.ua/jar/2FVDAiJvat Paypal: [email protected] Payoneer: [email protected] Дякую кожному за підтримку 🙏

В процессе обучения у любого человека появляются вопросы, которые могут показаться тупыми. И самое главное — найти такого Homo Sapiens или Neuronalis Rete, который терпеливо ответит на вопрос и объяснит почему этот вопрос тупой. Это сильно ускоряет и упрощает обучение. Когда такого человека нет, приходится разбираться самостоятельно или пользоваться услугами нематериальных собеседников. А эти вопросы — чуть ли не самая главная часть обучения. Тот, кому вы задаёте вопросы, должен иметь возможность не просто отвечать на поставленные вопросы, а помочь сориентироваться и понять, что, возможно, вопрос задаётся вообще не в ту сторону, а нужно совсем всё по-другому. Прежде чем начинать что-то учить, убедитесь, что у вас есть такой человек. Ну или не человек, если вы читаете этот пост в 2025 году.

В каментах к прошлому посту ожидаемо напомнили про GPT. Мол, с помощью этого сложно инструмента можно сильно упростить процесс обучения, задавая правильные вопросы и получая простые ответы. Давайте я вам напомню про то, чем на самом деле является (и ещё долгое время будет таким оставаться) современный ИИ в любом из его проявлений. Представьте себе, что вы находитесь в библиотеке, где все книги и рукописи написаны на неизвестном вам языке. Пусть это будет суахили. Вы понятия не имеете как закорлючки на бумаге отражают смысл, справа налево читать ли или сверху вниз, значит ли отдельный символ что-то или обязательно нужно его совмещать с другими символами. В общем, для вас это просто последовательный набор картинок, который предположительно как-то отражает какой-то смысл. И вот вам, через почтовую щель в двери на вход подают листок бумаге с написанными на нём знаками. Ваша задача — сформулировать ответ, записать его на листке бумаги и отправить назад. Обратите внимание, что никакого перевода на понятный язык нет, есть только литература на суахили. Как вы поступите? Самым логичным решением будет перебор всей доступной литературы в поисках подобных символов и попытке систематизации и выработке правил какие символы находятся вокруг тех, что вам подсунули. Задача не из простых и требует много ресурсов, но вас никто не торопит, развлекайтесь и анализируйте в своё удовольствие. И вот, изучив всё досконально и систематизировав, можно сформулировать и тщательно перерисовать иероглифы на лист бумаги, чтобы отправить в ответ. Вы всё ещё понятия не имеете что у вас спросили и не понимаете что же вы всё-таки ответили, но ответ сформулируете. Так даже целые беседы поддерживать можно, где собеседник будет вам возражать, спорить с вами и аргументировать свою позицию, но вы лишь будете подбирать усреднённый и наиболее вероятный ответ среди того, что у вас есть. Этот мысленный эксперимент называют "китайской комнатой", и появился он где-то по тем же причинам, как появился знаменитый кот Шрёдингера. В ответ на возмутительную формулировку, что же считать настоящим интеллектом, а что не считать. Напомню, что Кот Шрёдингера предложил один учёный (я забыл его фамилию), в ответ на теорию, что фотон меняет состояние с волнового на корпускулярного по велению некоего наблюдателя. В общем, нужно помнить, что современный ИИ — это всего лишь китайская комната и человечество сейчас ещё не до конца понимаем как отличить китайскую подделку от того самого сильного интеллекта. Со временем научимся, подстроимся, конечно, ведь в отличие от GPT люди всё ещё в состоянии адаптироваться под меняющиеся условия жизни, а оно не в состоянии. Оно не понимает вас, не пытается дать новых знаний. Оно всего лишь подбирает такой ответ, который мог бы быть записан в её бесконечной библиотеке. Да, делает он это чертовски хорошо, но сути это не меняет.

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

Із останнім збором на ремонт автівок нам допоміг бот @Donate1024Bot, який вирішує задачу «куди мені задонатити сьогодні?». Ідея дуже проста. Донатери підписуються на бот, і щоранку їм буде приходити повідомлення із новим збором. Всі піписники боту отримують одне й те саме, тому часто ми в той же день його закриваємо. Donate1024 знаходиться у ніші «маленьких фондів». Його фокус — маленькі збори на суми до 50-100 тис ₴ для закриття невеликих але дуже потрібних потреб: медицина, автівки та ремонти автівок, тепловізори та пнб, тактична амуніція, шоломи та бронежилети, дрони та обладнання для них, рації, генератори та дбж, спальники, сухпаї. Donate1024 це агрегатор зборів. Ви отримуєте текст збору, реквізити та посилання на збір у соцмережах, зазвичай це ФБ. У зборі обов'язково є монобанка, тому там відразу показують та оновлюють статистику. Всі збори ретельно перевіряються, приділяється увага: - Публічний профіль волонтера - Чи є репости та коментарі до збору - Чи робив волонтер збори раніше та чи звітував по ним - Монобанки моніторяться на предмет зняття коштів Ви завжди можете самі подивитися на все це, тому що ми даємо лінк на соцмережі, та прийняти рішення донатити чи ні. З початку роботи у кінці серпня ми опублікували вже більш ніж 200 зборів. На жоден з них не було скарг. По значній частині зборів вже є звіти, які теж публікуються у бот. Зараз половина зборів проводиться волонтерами, з якими команда боту знайома особисто. Трохи цифр: - Всього проведено 200 зборів - Загалом зібрано близько 6 000 000₴ - В середньому щодня донатить 70 людей - Середня сума донату ~500₴ Приєднуйтесь до підписників боту @Donate1024Bot, щоб допомагати не тільки великим зборам, накшталт ПЖ, КОЛО чи Фонду пана Притули, а й маленьким потребам. Це вкрай як важливо. Дякую за увагу.