Миллионы людей пользуются облаком Dropbox. Многие из них знают о возможности предложить идею нового функционала. Но только избранные ждут реализацию одной самой желанной фичи уже десять лет. В статье посмотрим, как Dropbox удаётся столь долгий срок не обращать внимание на потребности пользователей.
Как и любая концепция, утилитаризм не лишён критики. Тем не менее, с точки зрения разработчика программного обеспечения выглядит вполне разумным в первую очередь вносить в продукт изменения, желаемые большинством пользователей. А когда компании создают специализированные порталы и формы обратной связи с целью сделать глас народа громче, это не может не радовать.
Но не каждой сказке суждено стать былью.
Оглавление
Как всё начиналось
2008 год ознаменовался Олимпийскими играми в Пекине, мировым финансовым кризисом и терактами в Мумбаи. Поэтому неудивительно, что на фоне этих событий новость о рождении мало кому известной компании по облачному хранению данных теряется. И всё же Dropbox из заводи бизнес-инкубатора Y Combinator вышел в открытый океан реального рынка.
Я познакомился с детищем Дрю Хьюстона и Араша Фирдоуси в январе 2011-го будучи студентом. Кто-то из нашего потока посчитал хорошей идеей обмениваться учебными материалами через Dropbox. Я получил приглашение в общую папку группы, а товарищи, обладающие суперсилой записывать лекции, а не играть на них в Балду, стали выкладывать туда фотографии своих конспектов.
В июле 2012-го я купил аккаунт в Dropbox. Причина уважительная: я потерял файлы с музыкой собственного производства. Если точнее, то удалил их своими же руками. Сейчас уже и не вспомнить, как так вышло, но отныне хранить все важные данные в облаке стало непреложным правилом. Неприятности с жёстким диском и непослушными руками стали более не страшны.
С тех пор история Dropbox стала длиннее. 500 петабайт пользовательских данных были перенесены с ресурсов Amazon на собственные сервера, запущена линейка продуктов для бизнеса, приобретены несколько компаний, а доход превысил два с половиной миллиарда долларов в год.
Стремясь идти и дальше только вперёд, Dropbox запустил портал Ideas, дабы знать о желаниях пользователей и предоставлять им самые востребованные функции.
Есть идея!
Я время от времени создаю небольшие программы и утилиты для собственных нужд, а также разрабатываю библиотеку. Файлы, связанные с этими активностями мне, безусловно, дороги, а потому живут в синхронизируемой с облаком папке.
Но на каком бы языке программирования вы ни писали код и какую платформу ни использовали, в процессе разработки будут появляться автоматически создаваемые временные файлы и директории. Я веду разработку на C#, а сборка проектов в Visual Studio приводит к появлению папок bin и obj, которые синхронизировать с облаком нет никакого смысла.
Кто-то может заметить: “Ну и пусть себе синхронизируются, Интернет нынче быстрый”. Разумно. Но когда файлов много, процесс может занимать весьма заметное время даже с хорошей скоростью сети. Ведь загрузить один файл размера N не то же самое, что M файлов общим объёмом N. Второе будет дольше по понятным причинам: нужно для каждого файла отправлять отдельные запросы, возможно, открывать соединения, принимать ответы от сервера и т.д.
Есть и другой пример — папка obj, генерируемая утилитой docfx, с помощью которой я собираю сайт со справочными материалами для своей библиотеки. Временами там обнаруживались тысячи мелких файлов, синхронизация коих с облаком занимала не меньше часа. Помимо того, что это бессмысленная трата времени и пропускной полосы Интернета, приходилось держать компьютер включенным, пока Dropbox не закончит свои дела.
В какой-то момент это начало напоминать мазохизм, а он не входит в круг вещей, от которых я получаю удовольствие. Возникла естественная потребность в следующем функционале:
Указать паттерны имён файлов и папок, которые не должны отправляться в облако, оставаясь локально на компьютере. По сути, речь идёт о файле, аналогичном .gitignore в системе контроля версий Git.
Оказалось, что Dropbox ничем помочь не может, а людей, столкнувшихся с такой же проблемой, много. Тогда-то я и вышел на идею Add .dropboxignore directory to exclude folders without using selective sync, юбилей которой мы и собрались здесь все отметить.
Vox populi
Желание видеть свет лампочек, зажигающихся над головами пользователей, похвально. В статье How ideas shared on the Dropbox Community are inspiring new features коммьюнити-менеджер Эмма Фэй не скрывает благих намерений: компании важно слышать, какие функции и изменения нужны аудитории, и предоставлять их. Подчёркивается, что Dropbox относится к этому очень серьёзно.
Процесс выстроен просто: пользователь создаёт идею на портале Ideas, после чего другие голосуют за неё. Затем сотрудники Dropbox начинают менять статусы, решая, как быть с данной инициативой. В конце концов, если в компании согласны, что изменение будет полезно для продукта и его пользователей, то по окончании реализации будет выставлен статус Delivered.
В разделе All Ideas указано общее количество идей на данный момент — 889. При этом в статусе Delivered лишь 27. Наверное, это самые желанные предложения, с наибольшим количеством голосов? Нет. Более того, абсолютный лидер списка — обсуждаемая в данной статье идея — последовательно игнорируется компанией вот уже 10 лет. Выходит, что реализуется лишь 3 процента идей.
На сегодняшний день у виновника торжества 1300+ голосов, 600000+ просмотров и свыше 1000 комментариев. У ближайшего конкурента — отклонённой идеи Offline mode for Dropbox Paper web? — количество голосов не дотягивает и до 500, а просмотров и комментариев на порядки меньше. Что касается ближайшей реализованной, статистика такая: 200+ голосов, 70000+ просмотров и 150+ комментариев.
Прежде, чем мы порассуждаем, как так вышло, заглянем немного в историю.
Хронология событий
Касательно даты создания идеи я не уверен, но прямо сейчас на сайте значится 18 декабря 2014 года. Тем не менее, первый комментарий датируется 16 декабря 2014 года. Вряд ли у человека была машина времени, так что, вероятнее всего, правильный день рождения чуть раньше. Но доказательств у меня нет, так что будем опираться на официальные данные.
Как заметил один из пользователей, данная проблема уже возникала ранее у других людей. Например, в марте того же года и даже в январе 2012-го, а затем и в ноябре. Кое-кто даже реализовал данную функциональность сам (правда, проект давно нерабочий и был только под macOS). Иными словами, сразу стало ясно, что фича крайне востребованная. Все ждали ответа представителей Dropbox.
И 18-го же декабря 2014-го они ответили, посоветовав не хранить в папке Dropbox то, что не нужно синхронизировать с облаком. Эта же рекомендация была повторена и в марте следующего года.
Некоторые начали терять надежду и возмущаться. Всё чаще стали появляться сообщения об отказе от Dropbox и переходе к другим провайдерам облачного хранения. За годы обсуждения звучали имена таких продуктов, как MEGA, BitTorrent Sync (ныне Resilio Sync), pCloud, Sync и других.
При этом многие всё ещё верили, что Dropbox важно мнение своих пользователей. А потому продолжали появляться сообщения с детальным описанием необходимого функционала и примерами ситуаций. Люди даже были согласны на то, чтобы фича была недокументированной.
В июле 2015-го автор идеи связывался с поддержкой Dropbox, получив ответ, что комментарии будут переданы команде разработки. Я тоже имел контакт с ними (уже в 2022-ом, на восьмой год обсуждений) и получил ровно такой же ответ. При этом публично Dropbox отмалчивался вплоть до сентября 2015-го, когда было заявлено, что боль пользователей понятна, а фича обсуждается внутри компании.
А примеры этой самой боли продолжали появляться. Чаще всего звучало возмущение синхронизациями папок node_modules, где тысячи небольших файлов часами отправляются на сервер. Фигурировали и другие истории, в которых гигабайты временных данных безо всякой пользы уходят в Dropbox. Встречались и разработчики игр на Unity, синхронизация meta-файлов у которых также подчёркивает важность предлагаемой функции. Проблемы возникали и в LaTeX проектах.
В январе 2016-го количество голосов за идею превысило 200. А что же Dropbox? А Dropbox… читает дискуссию и понимает проблему. Другого ответа у компании нет. Впрочем, в 2018-м году сотрудники компании всё-таки решили честно заявить, что реализация фичи не планируется.
Разумеется, пошла волна разочарований, отказа от платных аккаунтов и рекомендаций продуктов конкурирующих компаний. Но не все теряли надежду, и в который раз появилось чрезвычайно подробное описание проблемы, которую должна решить рассматриваемая идея. После чего от представителей Dropbox было получено несколько сообщений, что комментарии переданы команде разработке (в который раз).
В июне 2019-го пользователь поделился забавным анонсом новой версии Dropbox Plus, присланным ему на почту:
The all-new Plus plan is packed with top-requested features.
При этом самая запрашиваемая фича, как вы уже догадались, отсутствовала в релизе.
Но, под конец года появилась надежда! Dropbox сообщил, что работает над функционалом, который позволит исключать файлы из синхронизации с аккаунтом. А спустя ещё 3 (!) года статус идеи был изменён на Delivered.
Свершилось? Как бы не так. Мы бы сейчас не собрались здесь в праздничных колпаках и с грустной улыбкой на лице. Предоставленное “решение” имеет ряд проблем, и мы разберём их подробно далее.
Через неделю под натиском громкого недоумения пользователей статус поменяли на Investigating. На восьмой день рождения идеи было высказано пророческое предположение, что мы отметим и десятый. И вот этот день настал.
Вспомним, что нам предлагали за этот долгий срок.
Предложенные варианты
Для простоты изложения минусов различных подходов будем пользоваться ранее показанным примером с директориями bin и obj, возникающими при сборке кода .NET. Суть не изменится, если подставить туда, например, папку node_modules и среду Node.js.
Хранение данных вне папки Dropbox
Самым первым вариантом решения проблемы Dropbox посчитал хранение информации вне синхронизируемой папки. И хотя очевидна вся абсурдность данного совета, опишем минусы подхода. Собственно, он один, зато огромный.
При сборке проекта будут появляться обозначенные выше папки. Причём создаются они автоматически внутри директории проекта. Наверное, есть способ куда-то их передвинуть, чтобы они оказались вне папки Dropbox, но так никто не делает и нет смысла заставлять пользователей усложнять свои процессы.
Можно предложить программистам использовать, например, GitHub вместо Dropbox. Но что если создаётся небольшая утилита для собственных нужд, которую не хочется отправлять в GitHub, а версионность не важна? Git также будет требовать выполнения команд отправки на удалённый сервер, сводя на нет прозрачность синхронизации с облаком. Да и зачем запрещать совмещать одно с другим — хранить Git-репозиторий внутри папки Dropbox? Более того, выше было показано, что функциональность нужна не только разработчикам программного обеспечения.
При этом, встречаются и защитники показанного предложения. Но, я надеюсь, такая крупная компания, как Dropbox, не воспринимает всерьёз комментарии вроде “Не знаю, зачем нужна эта функция, значит она не нужна никому”.
Selective Sync
Dropbox давно предоставляет фичу под названием Selective Sync. Нужно зайти в настройки клиентского приложения, и в огромном дереве папок снять галочки с тех, которые не должны синхронизироваться. При этом:
С выключенной галочкой папки будут удалены с компьютера, а в облаке останутся. Но bin и obj нужны как раз локально для запуска программ. Собственно, из папки bin они по умолчанию и запускаются.
Чтобы использовать функцию Selective Sync, данные нужно сперва отправить на сервер. Но рассматриваемые файлы изначально временные, они не должны попадать в облако никогда.
Создавая новый проект и получив новые папки bin и obj, нужно опять руками повторять всю процедуру.
Разумеется, на другом компьютере придётся выполнить те же действия.
Это даже не минусы, а решение совершенно другой задачи. При этом некоторые пользователи выкручиваются с помощью Selective Sync, закрывая вопрос с игнорированием данных.
Официальное решение
В конце концов, Dropbox дал возможность игнорировать файлы и папки. Конечно, сделав это по-своему, как будто пропустив мимо глаз всю многолетнюю дискуссию.
По мнению Dropbox пользователи должны каждый раз выполнять команду в контекстном меню или же выставлять через PowerShell специальный флаг, который сигнализирует клиентскому приложению о необходимости пропустить файл или папку. Проблемы:
Неочевидные трансформации папок при выполнении процедуры на разных компьютерах, синхронизированных с одной папкой Dropbox.
Указанные действия нужно выполнить на каждом компьютере.
Сведения о том, что файл или папку не нужно синхронизировать с сервером, исчезают при их удалении. Если удалить папки bin/obj, они автоматически пересоздадутся при следующей сборке. Разумеется, уже без флага исключения.
Пользователи отмечают, что файлы всё равно “трогаются” клиентом Dropbox, хоть даже они и помечены флагом. Это временами приводит к ошибкам компиляции из-за заблокированных файлов.
Файл или папка должны существовать, чтобы выполнение процедуры вообще было возможно. Такое ограничение не даёт возможности сказать “Не синхронизируй любую папку с именем X” до создания X.
Почему Dropbox так поступает?
И так, у Dropbox есть идея с огромным количеством голосов и комментариев, множество примеров и подробных изложений проблемы, но компания 10 лет игнорирует своих пользователей. Как такое может быть?
Всё упирается, вероятно, в нежелание сокращать объёмы хранимых пользователями данных. Прямо сейчас при покупке минимального тарифного плана пользователь получает хранилище в 2 ТБ. Два момента:
большинству столько не нужно;
обычно при аренде серверных мощностей оплачивается только используемый фактически объём.
Складывая первое со вторым получается, что в случае среднестатистического пользователя Dropbox платит за хранение данных размером намного меньше 2 ТБ, но человек оплачивает эти самые 2 ТБ.
Что случится, если предоставить возможность не синхронизировать тонну ненужных данных? Вместо условных 500 ГБ (из оплаченных 2 ТБ) на сервере будет храниться лишь 100. Мысль “Кажется, я немного переплачиваю” может зазвучать в голове громче. Так и до ухода к конкурентам недалеко.
А таковых в наши дни немало. Вот лишь некоторые варианты (цены указаны за год):
Google One: 100 ГБ за $20 и 2 ТБ за $100;
Microsoft OneDrive: 100 ГБ за $20 и 1 ТБ за $70;
Sync: 2 ТБ за $96;
pCloud: 500 ГБ за €50 и 2 ТБ за €100;
MEGA: 400 ГБ за €50 и 2 ТБ за €100.
Dropbox тем временем может похвастаться лишь 2 ТБ за $120. Не говоря уже о том, что некоторые из указанных выше продуктов имеют встроенный функционал игнорирования файлов и папок.
При этом запросов на более разнообразный ассортимент тарифов великое множество, например, Is there any smaller plan like 100 GB? или Can we have a lite plan?. К слову, я уже и забыл, а оказывается раньше была опция 1 ТБ. Так что повышение предоставляемого объёма и, как следствие, цены вполне вписывается в показанную выше стратегию компании.
Справедливости ради, встречались и запросы на более объёмные хранилища, например, Allow a personal account to have more than 3 TB или Personal plans with more storage.
В апреле 2023-го CEO компании сообщил об увольнении 500 сотрудников. Среди причин указано, что хоть компания и работает в плюс, рост замедлился. Видимо, Dropbox пытается различными способами повысить прибыль, так что надеяться на появление альтернативных тарифов или предоставление возможности сократить объём хранимых пользователями данных не приходится.
Заключение
Некогда Dropbox был если не единственным, то ведущим продуктом, предоставляющим облачное хранение данных. Использовать его значило получать качественный и надёжный сервис. К сожалению, громкое имя иногда играет злую шутку со своим хозяином.
Рынок изменился, широкий спектр облаков от разных компаний более не позволяет кому-либо из них быть явным лидером. Не является таковым и Dropbox.
В сети можно найти множество обсуждений, суть которых одна: Dropbox стагнирует. Компания не реализует новые действительно полезные функции и не слушает своих пользователей, хотя и предоставляет им рупор в виде площадки для публикации идей. По факту, данная площадка оказалась иллюзией того, что мы с вами можем повлиять на развитие продукта. Отмахивание от самой желаемой фичи в течение десятилетия — это нонсенс.
Согласно отчётам о прибыли, количество платных аккаунтов превышает 18 миллионов. А значит, несколько тысяч несогласных не сделают погоды. Так что до встречи через год!
Комментарии (128)
radioxoma
17.12.2024 18:08Сто лет не было Dropquest. Видимо их всё устраивает. Ну хоть старые бонусные Гб не отбирают у бесплатных аккаунтов.
waffel
17.12.2024 18:08У меня честно накрученные 16GB + ещё по акциям насобирал. В итоге - 29GB из которых 5 занято. Использую как буфер между пк и смрадфоном. Сливаются фотки которые потом пк подтягивает.
blind_oracle
17.12.2024 18:08SyncThing в помощь. Будет сливаться напрямую, без участия далёких облаков.
vikarti
17.12.2024 18:08Syncthing кстати еще относительно нормально работает в ситуации - "десятки тысяч каталогов, в них подкаталоги и файлы, и 150 Gb всего и это надо синхронизировать, включая обновления, в том числе на мобилки, при этом часть файлов могут быть открыты(в этом случае надо просто их не трогать пока)". Dropbox такое переносит не очень (OneDrive правда еще хуже это сносит)
djton1k
17.12.2024 18:08Забирают. В том плане, что имеющиеся файлы там еще хранятся, но вот новые уже не загрузить, пока не снизишь размер до "правильного" лимита
Devastator82
17.12.2024 18:08А как забирают? Я как накрутил себе году в 12-м 24 гб, так и использую по сей день. Не пропало ни гига
Akuma
17.12.2024 18:08На сколько помню позиция была типа «дропбокс не для хранения исходников». И в принципе я с этим согласен.
Если они начнут делать вот это вот все, им мозги ложечкой проковыряют, как это любят делать ИТшники для своих утилит. И нафиг это кому надо в общей массе.
Melanchall Автор
17.12.2024 18:08Dropbox для хранения файлов. Исходники тоже файлы.
Более того, даже в рамках дискуссии по обсуждаемой идее компания довольно быстро признала, что возможность исключать файлы из синхронизации людям нужна. В статье всё это написано. Написано даже, что нужно это не только программистам с их злополучными исходниками.
Есть опыт других компаний, которые возможность игнорирования файлов предоставляют. И никто мозги ложечкой им не ест.
Я уже не говорю о том, что (повторяю написанное в статье) Dropbox сам предоставил площадку для публикации идей и вот у них на руках самая желаемая фича, и они её игнорируют.
Gusotron
17.12.2024 18:08Тот факт, что дропбокс предоставил возможность рекомендовать идеи совсем не значит, что если идея собирает много голосов - она ДОЛЖНА быть реализована.
Дропбокс никогда не позиционировал себя как решение для удобного(!) хранения исходников. Никто не запрещает их вам там хранить, конечно, как кучу файлов. Но вы же не просите производителя ножей сделать их безопасными для детей потому что дети могут ими воспользоваться вскрывая замок и пораниться, правда?
ну короче, проблема высосана из пальца на уровне «абсолютно». Вы попросили посудомойку сделать минет, она отказалась, вы злитесь что «в брошюре написано пожелания принимаются и мое мнение важно!».
vorphalack
17.12.2024 18:08давайте без программистов. фотография. мне нужно хранить оригиналы отобранных фото (RAW), обработанные выходные жпеги и собственно всё. входящая папка с 30-50-150Гб равок и промежуточные папки для редактирования (кто пользуется Capture One - поймет) нахер не нужны ни в какой синхронизации. dropbox я, правда, тоже не пользуюсь, но вот готовый вариант, где нужно И дохера места И игнорирование определенных путей.
kAIST
17.12.2024 18:08Что за промежуточные папки для редактирования? Я как пользователь C1 не понимаю )
vorphalack
17.12.2024 18:08селекты, мусорка.
kAIST
17.12.2024 18:08Все равно не понимаю.
Импортируем папку в c1, если там делаем отбор/отбраковку, то это не трогает файлы на диске. Может быть у вас как то все настроено по другому, но, ИМХО, С1 не должен трогать файлы с равами вообще. Пишет спокойно в свою базу данных о том что фотографию забраковали и не трогает ее на диске.
Или мы о разных вещах говорим?
vorphalack
17.12.2024 18:08я ж говорю - у меня файловый режим, всех этих даз банных я наелся еще с лайтрумом, а значит в каждой папке, куда ходит C1 - есть подпапка CaptureOne, в которой по 3 файла метаданных на 1 картинку.
у меня типичная структура:
[съемка]:
_in
_out
_sel
_trash
на облако лить надо только _out (причем без внутренного CaptureOne) и _sel, 2 других должны быть чисто локальными.
dph
17.12.2024 18:08Хм, мой процесс работы с C1 предполагает
1) работаем с файлами RAW на диске
2) после обработки папки - делаем экспорт в JPG в архив для просмотра
3) после обработки файла - скидываем все без кэша в архив
И вот результат 2 и 3 летят в архив и в облако, реализуется простеньким rsync.
Но, конечно, Dropbox - не лучший вариант для хранения фотографий (дорого и неудобно).vorphalack
17.12.2024 18:08ну полностью процесс у меня сильно длиннее:
1. скидываем флешки на комп
2. запускаем exiftool, переименовываем их все под shutter count
3. запускам FastRawViewer, листаем фотки кнопкой delete
4. выжившее идет в _in
5. capture one, разглядывание, обработка и перемещение в _sel
6. capture one, второй круг уже по _sel, ненужное - в _trash, экспорт в _out
7. Lightroom на _out - второй проход шумодава, подписи.
8. полный экспорт - заказчику, остальное подчищается и _sel _out уходят на хранение на другой комп, _in _trash подчищаются через несколько дней - на всякий случай, вдруг какой-то важный кадр проморгал.
GDragon
17.12.2024 18:08Ваша задача прекрасно решается хардлинком нужных папок в папку которую уже синхронизирует дропбокс.
VADemon
17.12.2024 18:08А могла бы прекрасно решаться декларативной конфигурацией по исключению ненужных папок, без операций с файловой системой.
vorphalack
17.12.2024 18:08то есть мне на каждую съемку городить дополнительную пачку хардлинков и следить чтоб они не развалились?
GDragon
17.12.2024 18:08А как иначе?
Или вы представляете себе настройку "что не выгружать" в виде регулярок?))
vorphalack
17.12.2024 18:08банальные wildcards
*/_in/*
*/node_modules/*
итд
ну и да, я-то и все три типа линков создам - а менее подкованный фотограф? у меня куча знакомых, кто снимает сильно круче меня - но с компами чуть ли не на Большое Вы. им тоже fsutil осваивать?
acsent1
17.12.2024 18:08Все конечно решается. Но нужно чтобы было удобно. Иначе пользоваатели будут уходить туда, где смогли сделать удобно
Tirarex
17.12.2024 18:08Занимаюсь фото правда не в огромном масштабе, тоже не понял промежуточные папки. В том же лайтруме можно все в 3 клика отсеять и оценок фоткам наставить, а потом экспортировать только то что нужно. Все настройки лежат в маленьком файле lrcatalog, фотки в исходном виде в папке, во время редактирования их никто не копирует.
vorphalack
17.12.2024 18:08это у вас этот самый lrcatalog не разваливался никогда. пока я с этого угребища не ушел, у меня и sidecar xmp включены были и вся сортировка шла строго по физическим папкам, хватило один разок потерять ~ годовой каталог на несколько сот гигов исходников.
Tirarex
17.12.2024 18:08А зачем годовой каталог таскать? 1 проект = 1 каталог. Фото у меня на NAS, можно включить бекапы/версии, в таком случае даже если сломается то можно откатиться. Фото руками не копируются, автоматом скриптом улетают на нас как только флешка в пк появляется. Сеть 10гбит позволяет особо не думать о переносе на основной пк, и работать с фото напрямую на NAS.
Немного удивлен почитав ваши комментарии. Работа есть а пайплайн муторный и мануальный.
vhsreadonly
17.12.2024 18:08А каким образом у вас идет нейминг папки со съёмки, или все хранится в общей куче?
Tirarex
17.12.2024 18:08В моем случае все в куче так как смысла от разделения нет (На эту папку натравил Immich, таким образом у меня еще и поиск по обьектам и людям работает, а так же красивый и ультра быстрый веб гуи). Но ничего не мешает оставить скрипт авто копирования на NAS в папку аля "разобрать", откуда собственно фото пойдут по папкам разных проектов. Так как это все в рамках NAS, то (в моем случае truenas) не глупый, и при переносе файов поменяет их адреса но ничего никуда копировать физически не будет, тысячи файлов улетают за секунду. Собственно в папке проекта навести красоту с lrcatalog файлами и папками типа RawContent и DevelopedImages.
vcKomm
17.12.2024 18:08Подскажите, на чем вертится у вас immich? Хочу себе поставить, хочу определиться с железом, чтобы индексация работала
vorphalack
17.12.2024 18:08и что из этого мне вот прям надо автоматизировать? там самый долгий шаг -отсмотреть снятое, я с концерта и 4к кадров притащить могу (на выходе - 15-30шт на показ, плюс еще несколько десятков "для себя" или странных версий), остальные шаги просто какие-то крохи занимают.
Fox_exe
17.12.2024 18:08Вы создали продукт для клиентов. Клиенты хотят фичу, которая явно увеличит популярность продукта. Какой смысл не делать запрашиваемую фичу и терять прибыль?
(Тем более, что реализация фичи не затребует много ресурсов. Там буквально пол-сотни строк кода написать в клиент и всё).
Newbilius
17.12.2024 18:08> которая явно увеличит популярность продукта.
Для кого явно? Ответ на вопрос не так прост, как кажется.
Ну и про "
две строчки" "пол сотни строк" - это со стороны кажется просто, а на практике там может быть гораздо больше сложностей. Не будучи лично знакомым с кодовой базой продукта давать оценки сложности - дело такое себе)Fox_exe
17.12.2024 18:08Для кого явно? Ответ на вопрос не так прост, как кажется.
На сегодняшний день у виновника торжества 1300+ голосов, 600000+ просмотров и свыше 1000 комментариев
Вот для этих 1300+ человек (проголосовавших) это реально важно. А сколько ещё людей сочтут эту фичу весьма полезной, но не голосовали?
Newbilius
17.12.2024 18:08Популярность продукта - это число людей, которые им пользуются. Появление этой фичи не гарантирует, что им начнут пользоваться больше людей)
Ну и в реальности обычно из числа людей, которые просят какую-то фичу реально пользоваться ей будет... от продукта зависит, но в среднем, по личному опыту - от 10 до 50%. При этом отсутствие фичи не мешает им пользоваться продуктом, потому что для многих из них она третьестепенная. Будет - классно, не будет - ну и пофиг.
Melanchall Автор
17.12.2024 18:08Считаю пример с посудомойкой совершенно некорректным. Сервисы по облачному хранению данных оперируют файлами, поэтому вполне легитимно просить от них неких "улучшений" этих самых операций по обработке файлов. А отсеивать ненужные файлы (пользователь сам решит, что нужно, а что нет), как по мне, само собой напрашивается.
Но, разумеется, ваше мнение может не сходиться с мнением тысячи людей, желающих эту "высосанную из пальца" фичу.
RigelGL
17.12.2024 18:08GitLab CE, GitHub - ваш выбор. Версионирование, коммиты, Actions / CI/CD.
Вы можете настроить в гитхабе Actions так, что при пуше автоматически собирается новая версия вашей утилиты и кладётся в releases. Это ж круто. Можете сделать репу публичной и давать утилиту знакомым, им не нужно будет собирать из исходников.
С версионированием (и гитлабом/хабом) плюсов больше чем с дропбоксом. Я бы на вашем месте сделал выбор в пользу гитхаба, а не ждал пока облака прикрутят фичу игнорирования файлов.
Melanchall Автор
17.12.2024 18:08Но ведь я про версионирование вообще не говорил. Лично я важные проекты, разумеется, веду в GitHub. Но ничего не должно мне запрещать хранить эти проекты ещё и в Dropbox. Вообще в статье целый абзац есть касательно того, о чём вы говорите. Но пару моментов повторю:
У меня много утилит, которые я делаю просто, чтобы разово что-то проверить или сгенерировать. Я не хочу класть их в GitHub, создавать репозиторий, выполнять какие-то команды. Мне нужен просто бэкап этих проектов, чтобы я мог на другом компьютере их сразу же поиметь при синхронизации с облаком и всё.
Обсуждаемая в статье фича нужна не только программистам (в статье про это написано).
А как оно устроено у меня, можно почитать в статье Создание .NET библиотеки от А до Я. Там и GitHub и пайплайны и релизы и документация и чего только нет. Только это не должно мне запрещать использовать Dropbox простым способом: хранить там проект и не отправлять временные файлы в облако.
itmind
17.12.2024 18:08Git — это параллельный инструмент облачному хранению файлов, и одно другое не заменяет.
Есть, например, два ПК. Код одного проекта пишется и там, и там. Переключение между ПК происходит в течение дня. В случае использования Git пришлось бы в течение дня делать много комитов + пуш нерабочего кода для синхронизации между ПК.
Поэтому папка с проектом лежит в облачном хранилище и синхронизируется автоматически между всеми ПК. В проекте, естественно, используется git (Github с CI/CD), но комиты + пуш в удаленный репозиторий делаются только при завершении работы над фичей.
IvanBodhidharma
17.12.2024 18:08В случае использования Git пришлось бы в течение дня делать много комитов + пуш нерабочего кода для синхронизации между ПК.
И в чём проблема? Работайте в личной ветке, делайте коммиты и пуши хоть раз в 5 минут, как фича завершена, делайте рибейз и собирайте все промежуточные коммиты в 1 с закопченной фичей.
Ещё IDE может работать с исходниками на удалённой машине, например, по ssh, ничего синхронизировать не надо.
Вы какие-то бессмысленные костыли выдумыааете, имхо.
itmind
17.12.2024 18:08Проблема в том, что нужно не забывать каждые 5 минут делать коммит и пуш. Придется делать какую-то автоматизацию, которая будет через заданные промежутки делать коммит и пуш в нужную ветку, плюс проверять, есть ли вообще изменения. В общем, это не такой простой процесс. А с облачными хранилищами всё просто — поставил клиента и забыл.
Ещё IDE может работать с исходниками на удалённой машине, например, по SSH, ничего синхронизировать не надо
Другой ПК выключен, не имеет белого IP. В этом варианте тогда уже проще пользоваться облачными IDE (тем же GitHub Codespaces).
IvanBodhidharma
17.12.2024 18:08Придется делать какую то автоматизацию
Зачем? Перед тем, как идти за другой комп, сделайте коммит.
В этом варианте тогда уже проще пользоваться облачными IDE (тем же GitHub Codespaces)
Зачем? Положите в облако или на ваш "сервер" код и подключайте к нему десктопную IDE. Современные IDE давно так умеют.
itmind
17.12.2024 18:08Зачем? Перед тем, как идти за другой комп, сделайте коммит.
Пробовал, забываю. Допустим код пишется 30 минут, тут поступил звонок, срочно переключился на другую задачу, далее нужно ехать куда то срочно и т.п. Постоянно есть отвлекающие факторы. Да лишние это действия. Все что можно автоматизировать - должно быть автоматизировано.
У меня проблема бала только с проектами на Rust, т.к. там временных файлов на несколько гигабайт создается. Но проблема решилась путем вынесения этих файлов в директорию которая не синхронизируются (в cargo есть такая настройка)
Положите в облако или на ваш "сервер" код и подключайте к нему десктопную IDE. Современные IDE давно так умеют
В этом варианте на удаленный VPS ставится агент IDE и работа ведется через ssh. При этом сборка проекта происходит на удаленной машине. Нужно арендовывать другую VPS с хорошим процессором, что бы собирать проекты на Java, Rust, C++ т.к. там куча зависимостей которые компилятся и это очень долго на слабых ЦП.
Akuma
17.12.2024 18:08Допустим код пишется 30 минут, тут поступил звонок...вы уехали, а какой-нибудь скрипт в фоне на этом проекте остался. И он что-то делает с ФС постоянно, а дропбокс это все синхронизирует и в итоге вы не можете работать на втором компьютере.
Ситуации можно придумать в обе стороны.
IvanBodhidharma
17.12.2024 18:08Допустим код пишется 30 минут, тут поступил звонок, срочно переключился на другую задачу, далее нужно ехать куда то срочно и т.п.
Странная у вас работа какая-то. Это задача ваших админов поднять вам машину, на которой будет лежать и собираться код. Вы организационные проблемы пытаетесь техническими средствами решать, обычно ничего хорошего не получается из этого.
evtomax
17.12.2024 18:08Зачем? Перед тем, как идти за другой комп, сделайте коммит.
Зачем делать лишние действия, если можно сделать так, чтобы их не делать?
IvanBodhidharma
17.12.2024 18:08Судя по тому, что пишет предыдущий орпатор, он пытается решить организайионную проблему техническими средствами. Если вам постоянно нужно с разных компов работать, то нужна удалённая работа с кодом.
evtomax
17.12.2024 18:08Какую проблему решит удалённая работа с кодом, если вариант с синхронизацией прекрасно работает?
IvanBodhidharma
17.12.2024 18:08Не работает. Одну машину выключили, потом вторую включили и привет. Плюс, если бы всё работало, не было бы этой статьи. Есть нормальные, хорошо работающие инструменты для программистов, зачем пользоваться костылями, мне лично не понятно.
Я, при этом, не против синхронизации, сам её для бэкапов использую и фоточек, но для кода это тот самый троллейбус из хлеба.
N1X
17.12.2024 18:08Оно так в теории. На практике то, что говорят выше не лишено смысла.
Я вот тоже облаком для кода не пользуюсь, работаю на проекте и все лежит в репе. При пуше в ветку запускается CI и около 20 минут собирает проект. Сервер не бесконечно мощный и количество ранеров CI ограничено. Соответственно каждый пуш забирает ресурсы сервера и если пушит кто-то еще - все это выстраивается в очередь. Можно конечно настроить CI собирать только мастер и dev ветки, допустим, но тогда перед мержами нужно будет руками запускать CI для нужного коммита. Короче говоря в каждом случае нет "плохо" и "хорошо", есть нюансы. И если кому-то хотелось бы синхронизироваться через облако - возможно в их случае это действительно удобно. У меня тоже бывало что сидишь за стационарным компом, потом жена просит съездить куда-то с ней (и там нужно будет подождать минут 40). Хотелось бы просто взять ноут и продолжить работать с того же места. С репой нужно закоммитить состояние, убедиться что како-нибудь забытый stash не потеряется (в смысле не останется дома, т.к. туда что-то временно запихнул), короче много вариантов )
IvanBodhidharma
17.12.2024 18:08При пуше в ветку запускается CI и около 20 минут собирает проект. Сервер не бесконечно мощный и количество ранеров CI ограничено.
Зачем оно запускаеся, если не нужно? Можно отключить CI для пользовательских веток, можно даже для конкретных коммитов тегом в коммит мессадже.
У меня тоже бывало что сидишь за стационарным компом, потом жена просит съездить куда-то с ней...
Код на удалённой машине, я же писал. Удобная штука. Лучше всего в контейнере, чтобы окружение всегда одинаковое было и хоть с айпада работайте.
N1X
17.12.2024 18:08Зачем оно запускаеся, если не нужно?
Перед мержем в другие ветки все же нужно, чтобы собралось и тесты прошли. Я об этом писал - это просто пример. Здесь что-то поменять - в другом месте будут свои "за" и "против"
Код на удалённой машине, я же писал.
Которое тоже решение, просто другое, со своими плюсами и минусами: должна быть машина с белым IP, должен быть стабильный и постоянно активный инет. О вкусах фломастеров можно спорить бесконечно...
IvanBodhidharma
17.12.2024 18:08должна быть машина с белым IP
VPN можно использовать не только для обхода блокировок, но и по его изначальному предназначению.
быть стабильный и постоянно активный инет.
Как и для синхронизации. Причем, для синхронизации оно даже критичнее, т.к. при удалённой работе об отсутствии интернета вы узнаете сразу и примите меры, а в случае с синхронизацией вы узнаете о проблеме только когда уже сделать ничего нельзя.
А уж что начнёт происходить, когда вы файл без интернета и там и там поменяете... Собственно, для решения (в том числе) этих проблем с создали системы контроля версий, а вы добровольно от части их функционала отказываетесь. Это как сегодня продолжать прод на сервер по FTP заливать. Работает же, деды юзали и не жужжали...
Kenya-West
17.12.2024 18:08Включите Cloud Changes в VS Code (включается автоматом при входе в аккаунт Microsoft) и хоть в браузере работайте на github.dev или в vscode.dev. Можете и в обычном VS Code. И синхронизация Git не нужна.
Я так и пользуюсь, переключаясь с ПК на планшет, когда оказываюсь в кафешке. Очень удобно! Секреты и все изменения исходников автоматически появляются в репозитории, когда оказываешься в той же ветке.
Я ради этой фичи отказался от других редакторов и хранилищ Git, ибо прям чувствую, как наступает будущее, в котором можно в принципе не заморачиваться с синхронизацией - она просто есть и просто работает.
ihouser
17.12.2024 18:08Я для себя решил эту проблему просто:
Храню рабочие файлы в Dropbox, но, когда надо с ними работать, делаю софтлинк файлов в папку за пределами Dropbox. У меня специальная папка для работы. В линуксе софтлинк указывает на новое место а сохраняется в реальный файл. А всякие временные файлы пишется за пределами Dropbox папки.
Работает ли такое в виндовс я незнаю.
Melanchall Автор
17.12.2024 18:08Да, такие решения фигурировали в обсуждениях идеи. Но, как мы все понимаем, это костыли, и официальное встроенное решение было бы лучше.
LavaLava
17.12.2024 18:08Да, работает
Windows есть три типа файловых ссылок для NTFS томов: жесткие, мягкие (симлинки), точки соединения (Junction point).
Hard Links (жесткие ссылки) – могут указывать только на локальный файл, но не на папку. Такой файл – это ссылка на другой файла на этом же диске без фактического дублирования самого файла. У него отображается такой же размер и свойства, как у целевого файла (но реальное место на диске он не занимает);
Junction Points (Directory Hard Link, точка соединения) – могут указывать только на папку (на этом же или на другом разделе);
Symbolic Links (мягкая ссылка, симлинк) – могут указывать на локальный файл, папку и сетевой каталог на удаленном компьютере (UNC), поддерживаются относительные пути.
В подавляющем большинстве случаев вам будет достаточно функционала symbolic link, как наиболее универсального средства создания ссылки на любой объект.
Как создать символическую ссылку в Windows?
Для создания символических и жестких ссылок в Windows можно использовать встроенную утилиты mklink или PowerShell.
mklink утилита для создания симлинков в windows
MonkAlex
17.12.2024 18:08Годы назад перешел с дропа на мегу. Мега умеет фильтровать как минимум мусорные файлы, но я думаю и папки тоже можно. Использовал для фильтрации временных файлов у сохранений в играх, которые умудрялись иногда лимит сожрать (т.к. у меги лимит касается и удалённых файлов, а сейвы перезаписывались создавая для меги события "файл изменён" довольно часто).
Melanchall Автор
17.12.2024 18:08MEGA молодцы, они сделали именно то, что нужно: https://help.mega.io/ru/installs-apps/desktop/megaignore
Т.е. они позволяют создать специальный файл .megaignore и указать паттерны для исключения. И эта компания не посчитала, как некоторые в комментариях, что это ненужный функционал. Причём сделали они его даже без громких возгласов аудитории.
RieSet
17.12.2024 18:08Ребята сели и посчитали, сколько денег приносят эти ненужные файлы, и решили не делать фичу. Вы бы хотели создать фичу, чтобы себе зарплату уменьшить?
Arlekcangp
17.12.2024 18:08Как не странно, да. Потому что если вы будете годами игнорировать желания пользователей, то они в итоге перейдут к тем, кто их не игнорирует. Можно конечно попытаться посчитать, скольким клиентам нужна данная фича и каковы будут потери. Сравнить и в случае если уйдет меньше клиентов, чем будет потеря в доходах от новой фичи - не делать. Но это порочная логика, т к по факту вы сами себе конкурентов растите. А с их появлением и укреплением начнется настоящая борьба, которую с большой долей вероятности ваш менеджмент проиграет, т к он уже ориентирован не на улучшение продукта, а только на максимизацию прибыли. Таких примеров пруд-пруди. Чтоб далеко не ходить, можно даже дать что-то вроде предсказания: следующим очень крупным таким примером может стать компания Intel, котрая примерно из той же логики игнорировала улучшение в процессорах x86 последние 10 лет. Они не только не добавляли нового, а ещё и частенько вырезали старое под предлогом не нужности на десктопе. Ну теперь у их конкурента есть все шансы их повалить. Менеджмент уже закапошился, вот только виноватых всегда ищут не тех. Нельзя свою голову пеплом посыпать. =)
Управлять компанией, тем более монопольной или около-монопольной, опираясь только на показатель прибыли - это прямой путь к могиле этой компании. (разумеется если вы не крупный банк, страховое агенство, военная корпорация или крупный гос монополист. Этих всегда спасают и именно поэтому там управление сводится к тому, что бы либо сделать побольше дивиденды, либо отпилить кусочек от бюджета. Мой вариант борьбы с таким - расстрелы за коррупцию и измену родине. Пример - Китай)
RieSet
17.12.2024 18:08Могу предложить заняться разработкой систем анти-ИИ или осваивать, например, животноводство. Чтобы в будущем диверсифицировать свои знания и не остаться без работы (как интел).
Простите, но прислушаюсь к вашему мнению, только когда начнете управлять "около-монопольной" компанией. Пока это набор предположений
TimsTims
17.12.2024 18:08У нас на работе тоже вводили внутренний сайт идей. Любой сотрудник мог по любой теме предложить улучшение. Компания очень большая , тематик много. Отвечало за этот сайт всего пара человек (больше то и не надо). Когда приходит тикет - они его читают и тупо пересылают в профильную команду, чтоб почитала. Периодически их спрашивать - делать будете, берёте или нет?
И нам иногда прилетали идеи по нашему продукту. И я вам скажу, что большая часть всего что прилетело было либо бредом, либо человек просто не знал, что эта идея будет тупо нецелесообразна (например: давайте всем клиентам дарить крутые подарки после продажи). Короче 90% было мусором, и мы эти идеи просто слали нахер.
Были и толковые идеи, их очень быстро брали, реализовывали, а у самой команды и продакта был неразобранный бэклог идей на 2 года, каждая из которых реально приносила доход.
Я это к чему. В статье много говорится про такой сайт идей, но по факту это просто "приемная Санта Клауса", где работает 1 человек на полставки, который периодически пересылает тикеты продуктовым командам. Поэтому многого ждать от такой штуки не стоит, и процент реализации идей говорят сами за себя.
Я сейчас не говорю, что ваша идея говно. Вовсе нет. Я лишь говорю, что не стоит ждать от такого портала идей слишком многого.
Почему команда не сделала эту фичу за столько лет? Я считаю, проблема в технической сложности. Дропбокс был написан очень давно (уверен, второпях, ведь это был стартап с туманными перспективами), и за столько лет там накопилось столько костылей, что никто уже не понимает как вся эта слишком умная синхронизация работает. Целый час на перекачку 1000 файлов? Они их видимо майнят. И другой ваш пример, когда дропбокс все ещё "трогает" файлы, хотя не должен был - это яркий пример, как там всё всрато. Получается, за идею берется разработчик, понимает что ему слишком страшно трогать самую важную часть ПО, бросает задачу/либо же продакт думает он говно программист и увольняют бедолагу. Берут следующего, который что то там делает, но ломается другая часть ПО, тесты не проходят. И так по кругу все 10 лет :D.
Обычно, гораздо более рабочие каналы - это треды на reddit. Запустить там такой вой - и вуаля! Идею заметит их СЕО, скажет ребятам "чё за дела?" И те быстренько все сделают.
Melanchall Автор
17.12.2024 18:08Сложно поверить, что их CEO до сих пор не знает о таком фича реквесте :-) Но я понял, о чём вы говорите касательно недостатка внимания к порталу с пользовательскими инициативами. И для большинства идей такое вполне может быть. Но не для самой запрашиваемой, и не 10 лет.
Про сложности реализации возможно. Хотя это и удивительно (но бывает), что такая крупная компания не может за всё это время реорганизовать код. В принципе это тоже что-то говорит о продукте и управлении им.
Paulus
17.12.2024 18:08Самым первым вариантом решения проблемы Dropbox посчитал хранение информации вне синхронизируемой папки. И хотя очевидна вся абсурдность данного совета, опишем минусы подхода.
Очевидно также, что можно погуглить на тему in-source build vs out-of-source. Многие считают для проектов чуть сложнее "Hello, world" второй подход предпочтительным, хотя MS VS из коробки действительно предлагает по умолчанию первый вариант.
На сегодняшний день у виновника торжества 1300+ голосов
Согласно отчётам о прибыли, количество платных аккаунтов превышает 18 миллионов.
Даже если предположить, что все эти 1300 платят (хотя в реальности скорее наоборот), то эта фича интересует 0,007% покупателей. Вы бы стали решать такую проблему?
cinme
17.12.2024 18:08Я делал так:
Нужным файлам выставлялся атрибут Архивный
Скрипт по расписанию копировал все архивные файлы и папки в папку Google Drive
Google Drive копировал всё в облако.
vasyakrg
17.12.2024 18:08Я тоже довольно долго ходил вокруг да около этой задачи.
В итоге нашел https://kopia.io/, выставляю в ней фильтры на то, что не нужно, она по расписанию делает снапшоты данных и отправляет их в удаленный s3. Это не решает кейс: хочу работать в день за двумя разными компами, но я и не очень себе это представляю. Тут помимо данных мне пришлось бы все окружение (программы, настройки, картинку на раб столе наконец) тоже синхронить. А так и данные целы и версии есть (снепы делаются только по дифам практически мгновенно).
nixtonixto
17.12.2024 18:08Есть вариант лучше - использовать утилиту бэкапа. У себя делаю ею синхронизацию в одну папку для себя и коллег, и инкрементальные бэкапы по событиям в другую папку. У них обычно есть все необходимые фильтры с масками, например, как здесь:
Конкретно эта программа может бэкапить и в дропбокс, и в гугл драйв, и даже на роутер с флешкой/SSD по вебдав или фтп... Поэтому не понимаю страдания автора, 10 лет упорно не замечающего существование альтернатив.
me21
17.12.2024 18:08Плюсую, использую для этого FreeFileSync. Она умеет синхронизировать локально, с гугл драйв и SFTP/FTP. Мне хватает, синхронизирую папки проектов в папку OneDrive локально, а дальше уже OneDrive загружает всё в облако. Это, конечно, не дропбокс, но фичи фильтрации файлов у него тоже нет. Да, получается, что локально файлы хранятся два раза, но, может быть, это не так уж и плохо. Если хранятся локально на двух разных дисках -- это тоже повышает отказоустойчивость.
Revertis
17.12.2024 18:08А правильно ли я понимаю, что эту фитчу надо делать именно в клиенте? И если так, то можно ли использовать сторонние клиенты, или Dropbox их создавать запрещает?
Melanchall Автор
17.12.2024 18:08Да, нужна поддержка в клиенте. Ну и на сервере по части особой работы с файлом .dbignore (или как его назовут). Про создание сторонних клиентов не подскажу, были такие сообщения в дискуссиях, но я не заметил, чтобы в итоге кто-то счёл это реальным, нужно изучить.
Revertis
17.12.2024 18:08Можно без этого файла, задавать правила игнорирования в интерфейсе настроек папки.
И вот реально интересно, разрешается ли делать свои клиенты. Может можно было за 10 лет написать свой клиент.
TimReset
17.12.2024 18:08Вот да - например в стороннем клиенте Dropbox для Android, Dropsync, это пункт "Исключать скрытые файлы". Я это для Obsidian использую - он папку .obsidian (с точкой в начале) создаёт - и Dropsync её не выгружает. В Windows приходится PowerShell запускать, что бы добавить NTFS аттрибут. Вообще конечно ппц неочевидно.
aik
17.12.2024 18:08А может просто держать ваши рабочие проекты не в папке дропбокса, настроив синхронизацию своими силами любым сторонним клиентом? Хоть локально в папку дропбокса только нужное копировать, хоть прямо с облаком синхронизировать каким-нибудь rclone? А не ждать десять лет у моря погоды.
Ну, это ещё не касаясь того факта, что хранить в облаке информацию не стоит, должен быть оффлайновый бэкап за пределами папки синхронизации.
Melanchall Автор
17.12.2024 18:08Вы всё верно пишите, что не стоит ждать у моря погоды. Я уже и не жду, я у себя сделал примитивное решение в виде PowerShell-скрипта, который нужно запускать. Но мне кажется неверным видеть что-то неудобное и просто молча делать костыли с мыслями "Ну ладно". Всё же встроенное решение есть самый правильный путь, Мечты...
А оффлайновый бэкап всегда есть локально на компьютере. Хотя Dropbox позволяет включать режим online-only для сохранения места на диске (и некоторые им пользуются), я всё храню автономно на своём компьютере.
aik
17.12.2024 18:08я всё храню автономно на своём компьютере.
В папке дропбокса?
Melanchall Автор
17.12.2024 18:08Ну да. Есть папка на компьютере, которая синхронизируется с облаком. Но локально у меня ничего не удаляется. Отключусь от облака — локально всё на месте будет.
aik
17.12.2024 18:08Это если клиент дропбокса не заклинит и он не "синхронизирует" вас с пустым облаком. Были случаи. не конкретно дропбокса, а вообще.
Потому и нужна копия где-то за пределами папки.
makc9I
17.12.2024 18:08Сколько лет эта проблема существует, примерно столько же я с ней борюсь. В моем случае это исключение папки node_nodules. Поначалу делал символические ссылки на Винде, было костыльно и не удобно.
Потом нашел специальную программу, goodsync вроде, использовал ее. Тоже со своими проблемами. Она очень долго делала анализ того, что надо синхронизировать, поэтому настраивал ее на использование раз в час. И в облаке не всегда был свежий проект. Если кому-то нужно было отдать ссылку на актуальный билд, то "запускай синхронизацию руками и жди минут 15-30"
Потом дробпокс таки выкатил тему с исключением папки с помощью командной строки, тоже тот ещё гемор, конечно, но сейчас делаю так.
В какой-то момент эта опция появилась в контекстном меню, что было проще, чем вводить длинную команду, но потом, конкретно у меня, по крайней мере, вновь пропала.
Так что сейчас я вновь исключаю node_modules помощью командной строки. Но тут надо целый алгоритм выстроить, чтобы все работало:
Отключить синхронизацию дропбокс
Создать проект и установить зависимости, чтобы там появилась папка node_modules
Прописать исключение из синхронизации для этой папки
Включить синхронизацию
По итогу тоже довольно неудобно, конечно. Почему не могут сделать глобальный фильтр в настройках, не понятно
CitizenOfDreams
17.12.2024 18:08Это вы еще мобильное приложение Bandcamp не видели. Пользователи лет 15 просят сложнейшую фичу - возможность удалить трек из своей коллекции музыки.
vtal007
17.12.2024 18:08А какие другие "облака" позволяют указывать что вот те папки (а точнее тип папок) надо игнорить?
Всегда воспринимал облака именно как "хранилище", файлы, музыки, дистрибутивы
а при активной работе с этими данными, когда создаются какие-то временные файлы, я вообще отключал (в данном случае мейл-облако), чтобы оно не дергало диск, считывая постоянно возникающие новые временные файлы. Закончил работу - включил синхронизацию обратно
С Onedrive кстати тоже проблема, если на рабочем столе куча здоровенных файлов, то при их редактировании, изменении, добавлении. Или при медленном интернете.. Возникают затупы. А то и дубли появляются
Melanchall Автор
17.12.2024 18:08Ну, например, в MEGA сделали именно то, что требуется: https://help.mega.io/ru/installs-apps/desktop/megaignore
В Koofr тоже: https://koofr.eu/blog/posts/advanced-ways-to-exclude-files-from-sync-part-2
Есть зачаточное решение у pCloud: https://www.pcloud.com/help/drive-help-center/how-do-i-exclude-files-or-folders-from-my-backup-sync-or-ongoing-transfers-in-uploads
vtal007
17.12.2024 18:08это ж аналоги гитигнор? (у меги, который)
а чего им гит не устраивает?
или любой другой локальный сервис синхронизации
Ну типа работаем в папке рабочей, раз в сутки запускается скриптик, который копирует из рабочей папки в папку облака
собственно на многих работах, так и делают, содержимое раб стола и мои документы либо сразу находится на сервере, либо туда копируется регулярно. причем даже некоторые кол-во дней хранятся версии(ну то есть принцип как на сервере, никто ж не делает синхронизации на боевом сервере, раз в сутки делают бекап, ночью)
а так, ну вот это хранилище не поддерживает гит игнор или мега-игнор, ну так можно использовать другие варианты
Кстати с точки зрения разработки, а пароли то ? где пароли? не утекают они тоже в облако? А если нет, если пароли лежат в файлике отдельно, значит если полетит ссд-шка, то все, данные то у нас в облаке, а пароли пролюбили
IvanBodhidharma
17.12.2024 18:08rsync --exclude-fromStorage Box на 1 TB у Хетцнера можно купить за $40 в год. На кой чёрт для бэкапов нужен дропбокс и все остальные перечисленные в статье клауды?
aik
17.12.2024 18:08Облако всё делает за вас - хранит, синхронизирует, ведёт историю, читает ваши файлы и сливает их данные третьим лицам...
tester12
17.12.2024 18:08Облако (по идее) хранит файлы более профессионально и надёжно: не на одном серваке (как в Storage Box у Hetzner), а несколько копий в географически распределённых ЦОДах.
"Сливание данных третьим лицам" предотвращается шифрованием папки (простейшим encfs).
aik
17.12.2024 18:08Как повезёт. Зачастую эти копии в одном датацентре, пусть и на разных серверах. Но, в любом случае, это чужой дядя. И он в любой момент может ваши файлы грохнуть или доступ к ним прикрыть. Без злого умысла, просто так получилось.
Мои основные принципы работы с облаками:
1) Считай, что всё, загруженное в облако, ты сразу открываешь на доступ неопределённой группе лиц. Так что приватное не туда не класть, а если всё же кладёшь - шифруй.
2) Данные в облаке и папке их клиента не хранить, всегда должна быть актуальная копия где-то в сторонке.
crawlingroof
17.12.2024 18:08После того как убрали веб сервер на папку, пользоваться им стало совсем грустно.
freylis
17.12.2024 18:08Странно, но никто не упомянул яндекс.диск. Переехал с дропбокса в момент, когда они отменили бесплатный тариф, сначала на бесплатный диск яндекса, а сейчас уже покупаю. И чем дальше, тем больше мне он нравится. Да, сначала стабильность хромала (именно api), но сейчас проблем давно не испытываю. А с вводом возможности покупать место сразу на семью, так вообще ничего другого и не нужно.
StjarnornasFred
17.12.2024 18:08Есть мнение, что пользоваться сервисами Яндекса - зашквар и моветон для любого продвинутого айтишника, и что от яндекса ничего хорошего быть не может. В действительности это, конечно же, не так, я с удовольствием пользуюсь всей экосистемой и доволен как слон. Большинство сервисов Яндекса удобнее и функциональнее аналогов. К Диску главная претензия - иногда плохо работает WebDAV плюс нужно создавать отдельный пароль. Однако УМВР и для меня единственный недостаток - невозможность загружать на бесплатном тарифе (даже с подпиской Плюс - ну как так!) файлы свыше 1 ГБ.
К Яндексу, и вообще к российским сервисам, ещё есть вопросики вне технической части - но вообще-то их стоит адресовать по другому адресу.
adeshere
17.12.2024 18:08...невозможность загружать на бесплатном тарифе (даже с подпиской Плюс - ну как так!) файлы свыше 1 ГБ.
Счастливый Вы человек! Если совсем припрет, Вам достаточно добавить совсем немного рублей, и вуаля - здравствуйте, файлы по 50Гб! А мы вот уже уперлись в планку 50Гб... .И, кажется, она не будет преодолена никогда :-((
А как все хорошо начиналось...
Давным-давно, когда всем еще хватало 640Кб, у нас уже были временные ряды размером под мегабайт. Или поменьше, но сразу десяток. Монстры типа Мезозавра с ними работать отказывались, да и вообще выглядели ущербным убожеством по сравнению с нашими представлениями о прекрасном. В общем, мы тогда запилили собственную узконишевую СУБД временных рядов с весьма нестандартной архитектурой и минимальными пожеланиями к "механической части". Которая уже почти сорок лет постепенно докручивается под наши задачи, так что сейчас она вполне себе может покуривать гигабайтные временные ряды на самом убогом железе родом из 2000-первых. Лишь бы диск был большой и быстрый (ну и кэш желательно поумнее, если, конечно, на компе есть свободная ОП). Так бы мы с ней и жили в благоразумии и достатке... только вот недавно один мой коллега перепутал по глупости буквы в компьютере, и закинул нашу общую базу на Яндекс-диск. После чего неожиданно выяснилось, что наша древняя СУБД прекрасно работает с этим диском. Т.е. нам теперь больше не нужно пересылать свои базы друг другу тайными тропами: достаточно залить данные в облако, и вуаля: теперь с БД могут работать сразу несколько юзеров из самых разных локаций
Точнее, если быть честным, то совсем одновременно не могут, но это уже отдельная история. Впрочем, она прикольная, так что я, пожалуй, и ее расскажу
Вообще-то наша СУБД всю жизнь была персональной, то бишь однопользовательской. Никаких тебе механизмов авторизаций, прав доступа и т.д. Только свой личный комп, файлы с данными и довольно простая программа, которая обеспечивает интерфейс между файлами данных и интегрированной с ней средой анализа/обработки рядов. Только вот по мере появления новых юзеров из научной среды (многим из которых было под 70), неожиданно выяснилось, что такую примитивную беззащитную базу довольно легко поломать. А именно, если юзер забыл, что база уже открыта в одном окне, и запустил второй экземпляр программы, то они начинали конфликтовать. В лучшем случае просто ругались на отсутствие доступа, а в худшем (при попытке одновременной записи в базу) и вовсе могли там что-то испортить. Короче, чтобы не искушать судьбу, я на коленке сделал простенький механизм блокировки, чтобы второй экземпляр программы не мог открыть базу, пока над ней издевается альтернативный клиент. Его и механизмом-то назвать сложно: де-факто это просто флаг в специальном служебном файле. Какая проблема (читай защита от дурака), такое к ней и решение ;-)
А хохма произошла в тот миг, когда мы закинули свою базу на Яндекс-диск и начали с ней работать одновременно из Пущино, Москвы и с Камчатки. Я не могу логически объяснить произошедшее недоразумение, но внезапно выяснилось, что этот простенький механизм родом из 1990-х вполне себе справляется с управлением доступом к облачной базе. Юзеров у нас мало, запись в базу происходит лишь по большим праздникам, поэтому синенькое окошко с надписью "подождите минутку, пока база освободится" не напрягает вообще. Вот тут-то, подумал я, карта нам и попрет... Да вот не тут-то было.
А проблема в том, что у нас многие ряды 100-герцовые. А программа все же не настоящая СУБД, и архивировать данные "на лету" не умеет. Так что на каждое значение временного ряда ей два байта вынь да положь, а то и четыре... А 100Гц - это 3Е+9 значений в год, которые удобнее всего хранить в одном пополняемом файле (у нас каждый сигнал - это отдельный файл). Короче, лимита 50Гб хватает максимум на несколько лет измерений. Можно, конечно, делить длинные ряды данных на части, а перед анализом склеивать (рабочее пространство программа себе все равно организует на локальном диске для скорости), но это уже совсем не тот коленкор :-(
В общем, проблему 50 гигабайт мы так и не можем пока решить. Буду благодарен, если кто-то подкинет идею, как это ограничение обойти. Проблема в том, что нам при работе эти файлы нужны в натуральном виде, неупакованные. Чтобы программа могла в любой момент сделать open и немедленно прочитать/записать из файла значение по произвольному заранее известному адресу. Причем читаются только данные, и обычно последовательными блоками; timestamp при этом нигде не хранится, а вычисляется за пренебрежимо малое время. Т.е. побочные "накладные расходы" равны нулю. Скорость ограничивается исключительно диском. Поэтому данные хочется получать так быстро, как только система физически может их отдавать.
Ну и еще очень хочется, чтобы в случае изменений в файле процесс синхронизации с облаком начинался немедленно, а не после того, как его кто-то заархивирует. С небольшими файлами (до 50Гб) все именно так и работает. А как быть с большими?
funca
17.12.2024 18:08Разбить файлы на части для кастомной базы вроде не должно быть супер сложной задачей.
adeshere
17.12.2024 18:08С одной стороны - да, не сложно. Собственно, на уровне юзера нам никто не мешает это делать прямо сейчас. Но это морально тяжело, да и вообще как-то "без уважения" (с). Ибо при каждой загрузке данных в рабочее пространство юзеру придется надевать на голову шапочку с бубенцами и совершать некое танцевальное па.
Можно сделать и на уровне СУБД, конечно. Но во-первых, это здорово запутает логику алгоритмов. Сейчас-то у нас один ряд = один бесконечный файл. Проще не бывает. Как говорится, работает-не трогай. Да и зарплата у нас идет за выкопанные кубометры данных, а вовсе не за прикрученные к самодельной лопате фичи. Ну и вообще, хочется тратить время на более творческие задачи, а не на борьбу с техническими ограничениями...
А во-вторых, в существующей архитектуре БД возможность такого дробления ряда данных на несколько файлов не предусмотрена. Придется менять не только коды программ, но и форматы системных (служебных) файлов БД. Это неминуемо нарушит обратную совместимость. Чего нам делать крайне не хочется, т.к. мы постоянно передаем свои базы между коллегами, а в этом случае любая база, сделанная в новой версии программы, перестанет читаться в прошлых версиях. Для нас это
практически табу
что неудивительно, если вспомнить, что все написано на фортране ;-)
Который, между прочим, до сих пор обязан компилировать код родом из 1960-хх
А если серьезнее, то в последний раз мы нарушали обратную совместимость при переносе всей системы из DOS в Windows. Там просто деваться некуда было. Разумеется, при этом мы зарезервировали тьму полей для будущих расширений (примерно половина из которых уже использована). Но вот разбиение сигнала на несколько файлов в эту систему не вписывается от слова никак.
legolegs
17.12.2024 18:08Так выкиньте яндекс.диск из уравнения и перейдите на syncthing. У него и минусов - отсутствие своего хранилища, но для тех, у кого своя машина онлайн это не проблема. Ну или скрипт-обёртку вокруг rsync, но это уже требует скила.
adeshere
17.12.2024 18:08Так выкиньте яндекс.диск из уравнения и перейдите на syncthing.
Спасибо за наводку! Почитал вики, выглядит интересно! Хотя одна проблема сразу видна: у нас нет постоянно работающих машин. А для синхронизации надо, чтобы они были в сети одновременно....
И в продолжение темы: я правильно понял, что Вы им пользуетесь?
Можете ли тогда уточнить пару нюансов?
1) Как syncthing определяет, где самая последняя версия файла? По дате? Я имею в виду случай, когда машин много, и они подключаются к сети не одновременно. Скажем, машин четыре, но онлайн они обычно бывают попарно в разных комбинациях. Например, пускай самая свежая версия файла у нас на компе N1 (ее добавили, когда он был офлайн). Потом в сети появляются N1+N2, файл синхронизировался, все Ок. Затем N1 и N2 отключились, а в онлайне появились N3+N4. Запоминает ли где-то прога, что на машинах N1 и N2 есть гораздо более новая версия файла, и поэтому синхронизировать N3 с N4 нет никакого смысла? Т.к. надо ждать заонлайнивания N1/N2 и сразу качать оттуда?
И вообще, сообщит ли syncthing юзерам N3+N4 о возникновении такой ситуации?
.
2) Что будет, если две машины N1+N2 обе были в офлайне, и юзеры отредактировали один и тот же файл каждый у себя? Потом оба компа заонлайнились. Прога заметит, что изменены ОБА файла, или тупо синхронизирует по дате? А если заметит, то что будет дальше?
.
3) И третий вопрос. Можно ли как-то спросить у syncthing, синхронизирован ли У МЕНЯ некий файл X, или же его синхронизация идет прямо сейчас в данный момент? Например, можно ли послать соответствующему процессу сообщение с просьбой вернуть статус файла? Или легально прочитать этот статус в служебном файле syncthing?
На Я-диске такого сервиса нет (только неполноценный синенький индикатор в панели задач, показывающий, что синхронизация чего-то там продолжается). Нам это не очень удобно, т.к. вынуждает использовать всякие костыли. Вместо того, чтобы напрямую задать этот вопрос Я-API, мы сейчас пишем в облако небольшой дополнительный служебный файл со статусом базы, и пытаемся по нему определить, выждав паузу, завершилась синхронизация, или нет. В надежде, что этот микрофайл синхронизируется достаточно быстро (что никто нам не гарантирует, на самом деле)
.
4) Ну и четвертый вопрос. По идее глупый (в наше время странно предполагать иное, но мало ли). Если одна из машин отваливается во время синхронизации, то после переподключения синхронизация продолжится того же самого места, правильно? Даже если целевой файл изменился?
Более точно: у нас чаще всего начало файла не изменяется, но к нему могут добавляться новые куски в конце. Из вики я понял, что syncthing такие штуки умеет отслеживать, и будет синхронизировать только эти изменившиеся куски, так? Так вот, если во время синхронизации такого куска связь прервется, а новое включение произойдет уже после того, как к файлу добавится еще что-то, то такая ситуация обработается корректно?
.
Заранее спасибо за ответы! Если Вы в курсе этих деталей, конечно...
Cekory
17.12.2024 18:08С Яндекс диском очень медленная синхронизация через rclone. Насколько помню, Яндекс принудительно замедляет трафик от rclone.
А вот облако мэйл ру, как ни странно, работает с rclone очень быстро и без сбоев. Так что предпочел его.
foldr
17.12.2024 18:08Было бы интеересно узнать, как это реализовано у других файловых хранилищ, приведенных в статье
Google One
Microsoft OneDrive
Sync
pCloud
MEGAВыглядит как наезд конкретно на дропбокс, при этом непонятно, на сколько это вообще сложно реализуемая фича (иначе была бы у всех конкурентов). Я склонен согласиться с другими комментаторами, что если бы так было просто реализовать, то уже сделали бы. А отчитываться почему не могут/не хотят они не обязаны
P.s. не отрицаю наличие проблемы, самому не нравятся предлагаемые настроки синхронизации, приходится костылить
Melanchall Автор
17.12.2024 18:08Выше написал комментарий, повторю:
Ну, например, в MEGA сделали именно то, что требуется: https://help.mega.io/ru/installs-apps/desktop/megaignore
В Koofr тоже: https://koofr.eu/blog/posts/advanced-ways-to-exclude-files-from-sync-part-2
Есть зачаточное решение у pCloud: https://www.pcloud.com/help/drive-help-center/how-do-i-exclude-files-or-folders-from-my-backup-sync-or-ongoing-transfers-in-uploads
Кстати, забавно, что именно самые крупные сервисы облачного хранения не реализуют данную фичу: Dropbox, Google, Microsoft. Хотя реализация данной штуки, хоть, возможно, и не значительно, но была бы преимуществом перед конкурентами.
Наезд на Dropbox связан с наличием портала, куда пользователи могут публиковать идеи, с наличием самой запрашиваемой фичи и с откровенным безразличием к такой идее со стороны компании в течение 10 лет.
markowww
17.12.2024 18:08Примерно такая же ситуация была с Confluence. Вертикальное выравнивание в ячейках таблицы делали больше 10 лет. Хотя, казалось бы... Для self-hosted реализовали год назад (причем для более дорогого Datacenter edition), а для облачной версии ждем до сих пор...
mopsicus
17.12.2024 18:08Для себя решил проблему с помощью Syncthing. Планирую таким же способом уйти с Google Photo – поставить Immich и синкать все фото и видео с телефона.
rkfg
17.12.2024 18:08Причём, у них давно уже есть игноры с шаблонами. Достаточно туда бахнуть
node_modulesи подобное и забыть. Вылизывали они это всё долго, но можно понять — система децентрализованная, и граф устройств и папок может быть аболютно произвольно-безумный. Вдобавок, между платформами бывают разные соглашения об именовании файлов и директорий: некоторые символы запрещены на некоторых ОС (типа windows), где-то названия регистрозависимые, где-то нет, где-то длина имени файла или пути лимитирована одним числом символов, а где-то другим, и байтов, и всё это должно в любых комбинациях работать, не удаляя внезапно файлы. Но вроде уже несколько лет никаких проблем не было.legolegs
17.12.2024 18:08Файлы с двоеточиями в названии (напр. скриншоты с временем) всё ещё создают неудобства. Ну это не в софте дело, что уж тут поделать, кроме как переименовывать на источнике.
rkfg
17.12.2024 18:08Это понятно, просто было бы хуже, если на линуксе добавил двоеточие в имя, а на винде при этом файл удалился вообще. Чуть менее хуже, если на линуксе появится дубликат без двоеточия, отзеркалившись от винды.
DenSigma
17.12.2024 18:08Такое впечатление, что люди создают проблемы и обижаются, что их не решают. Проекты и исходники надо хранить на гитхабе.
Лично я использую дропбокс для синхронизации с читалкой и не пихаю в бокс все подряд.
Мне нравится подход дропбокса. Мы разработали продукт и он умеет ровно вот это (список). Не более. Впихивать туда все хотелки и идеи всех пользователей мы не намерены. Можете покупать, если он вам подходит. Если не подходит - походите по рынку.
Обижаться на продавцов автомобилей, что их продукт не умеет копать землю (а чо такова? Колеса есть, осталось прикрутить ковш! Очень полезная фича, многим нужна.) глупо и бесперспективно.
netch80
17.12.2024 18:08Проекты и исходники надо хранить на гитхабе.
Домашний каталог с исключением всех ~/.cache/
Общий каталог работ, в котором далеко не всё можно и имеет смысл коммитить, и при этом у каждого подкаталога может быть своя специфика, что не синхронизировать.
Это с ходу. Могут быть и более хитрые случаи.
Обзывать всё, что не подходит под тупой шаблон, "исходниками" и посылать на гитхаб - некорректно.
MountainGoat
17.12.2024 18:08В одном месте, закончив кодить
git bundle ~/dropbox/mirai.bundleПотом в другом
git fetch ~/dropbox/mirai.bundleА прямо в Dropbox сырцы хранить - ну такое...
CitizenOfDreams
17.12.2024 18:08А кстати, почему люди для синхронизации файлов между устройствами пользуются облачным хранилищем, а не средствами для собственно синхронизации? Я понимаю сценарий, когда основной компьютер один. Но когда у пользователя есть домашний комп, рабочий комп и ноутбук - зачем передавать четвертую копию файлов товарищам майорам, искусственным интеллектам, рекламодателям, хакерам и вообще всем желающим?
Newbilius
17.12.2024 18:08А какие альтернативы?
Либо ручками таскать на флешках, что не очень удобно
Либо синхронизация в режиме "устройство 1 -> устройство 2", когда оба должны быть онлайн, что не очень удобно
Либо какой-то промежуточный сервер-хранилище обязательно появится. Самому его поднимать или брать готовый - вопрос цены и трудозатрат.
aik
17.12.2024 18:08Потому что облако постоянно включено и доступно отовсюду. Компьютеры и прочие ноутбуки зачастую сидят за файрволами и прямой доступ между ними не так просто бывает организовать.
CitizenOfDreams
17.12.2024 18:08Потому что облако постоянно включено и доступно отовсюду.
Ну да, забыл, у некоторых людей есть привычка постоянно включать-выключать домашний компьютер. Тогда да, вечнодоступное облако.
Компьютеры и прочие ноутбуки зачастую сидят за файрволами и прямой доступ между ними не так просто бывает организовать.
Syncthing вроде не жалуется на файерволлы, отсутствие белого IP и прочие неудобства. По крайней мере мне не пришлось ничего делать, только установил и сказал: вот здесь синхруй, вот здесь не синхруй.
Либо какой-то промежуточный сервер-хранилище обязательно появится.
Скоро у всех и так VPS будут, потому что без них только с Яндекс-диском связь и останется. Да еще с Госуслугами и Мейл.ру, чтоб электронные повестки приходили.
aik
17.12.2024 18:08у некоторых людей есть привычка постоянно включать-выключать домашний компьютер.
Не у некоторых, а у большинства. И рабочий тоже. А уж ноутбук постоянно включенным и в онлайне точно никто с собой не носит.
По крайней мере мне не пришлось ничего делать, только установил и сказал: вот здесь синхруй, вот здесь не синхруй.
А мне пришлось ещё порты пробросить, чтобы скорость нормальная была точка-точка, а не через релеи всё шло на 10 мегабитах.
Скоро у всех и так VPS будут
Во-первых, не у всех, во-вторых, впс с большим диском стоят сравнимо с облаками. Я вон яндекса купил на 2ТБ только потому, что это по акции выходило дешевле, чем мой тариф на 100 гигов на год продлять. Обошлось что-то типа 700 рублей в год.
Kovurr
17.12.2024 18:08После того как они вместо старого удобного клиента выкатили тормозное чудище, ушел на мегу и не жалею.
nourish
17.12.2024 18:08Достаточно узкая проблема. Конечно, .dropboxignore — это было бы лучше, но решение-то есть. У меня некоторые проекты тоже в Дропбоксе, мне удобно. Синхронизацию папок типа node_modules отключаю обычным способом через командную строку: https://help.dropbox.com/sync/ignored-files. Но мне, правда, это приходится делать условно раз в полгода.
Melanchall Автор
17.12.2024 18:08Да, я тоже PowerShell-скрипт сделал и вызываю при необходимости. Но да, встроенное решение было бы лучше.
VADemon
17.12.2024 18:08Тем не менее, первый комментарий датируется 16 декабря 2014 года.
Опубликована тема была действительно 18-го (26 minutes ago), но ни одна ссылка с той страницы не была проархивирована. А в более поздней версии от 2022-12-05 (раньше нету) я заметил, что наверно разработчик Christopher N.1 (2014-12-18 11:38AM) закинул комментарий от Antoni A. (2014-12-15) в свежесозданную тему (2014-12-18 11:16AM). Откуда - не ясно. That's all, folks!
Mox
17.12.2024 18:08Идея хранить исходники в git не такая уж плохая.
mk2
17.12.2024 18:08Как в системе контроля версий? Безусловно.
А как хранить и синхронизировать их в облако - это другой вопрос. Если имеется в виду "на GitHub" - приватные репозитории стоят денег, а выкладывать свой код на всеобщее обозрение не хочется.
Выше озвучивали вариант с git bundle. Или можно хранить в Dropbox только папку .git, а непосредственно рабочую папку создать с помощью git worktree, тогда все конфиги репозитория будут тоже синхронизироваться.
MonkAlex
17.12.2024 18:08Приватные на гитхабе вроде больше не стоят денег, я недавно завёл приватную репу.
Mox
17.12.2024 18:08Приватные репозитории бесплатны и на github и на gitlab, поэтому как раз непонятно - нафига хранить это все в платном DropBox
YmHuKMuIIIKa
17.12.2024 18:08Забавно, как много здесь ультимативных комментариев типа "сорцы надо хранить на гитхабе. Точка." Ну может, сорцы и надо. Хотя мне очень не хотелось делать всякие официальные репозитории для говнокодерских скриптов с решениями разных задачек с проекта эйлера и прочих литкодов. По ряду причин. А хранить их хотелось.
Но почти полностью игнорируется тред про фотографии. А я не уверен, что грузить кучи промежуточных изображений (я не фотограф, возможно, не понял до конца) в гитхаб - крутая идея. Или, допустим, некоторые ml-модели обученные.
Да, конечно, советы типа "ну вынесите куда-то далеко нужные папки, до которых дропбокс не дотянется" имеют право на жизнь. Или "наделайте линков". Но некоторым очень не хочется менять наработанный за годы пайплайн рабочего процесса. Куда проще было бы использовать фичу, которая кажется очевидной для сервиса, который "просто синхронизирует файлы с облаком" — синхронизировать не все файлы. С возможностью уточнения понятия "не все".
Melanchall Автор
17.12.2024 18:08Сам был удивлён, сколько людей мыслят в духе "Мне это не нужно, есть обходные варианты, значит фича ненужная!". И одно дело просто предложить другие способы на подумать, но нет, именно ультимативно заявляется, что идея неверная.
При этом сколько уже было сказано, что функционал нужен не только программистам (это и в статье есть). А даже если и программистам, то не все проекты хочется публиковать (пусть и в приватные репы) на GitHub. Если я подключу второй компьютер и захочу поиметь все эти мелкие квазипроекты на нём, мне на всё репы заводить и git clone вызывать? Действительно, удобно.
vorphalack
17.12.2024 18:08в моем случае не промежуточных - а входящих. все 30-130 гигов отснятых исходников, из которых 95% будут удалены через двое суток.
claimc
17.12.2024 18:08Спасибо. Я сам долго мучился с вопросом фильтров в дропбоксе. Вчера, благодаря статье, пересел на MEGA, и с утра испытываю невообразимое счастье. Файлов синхронизации уменьшилось на 200к благодаря фильтру node_modules и нескольких временных папок. К тому же при включенном дропбоксе проводник windows жутко тормозил. Сейчас отклик проводника девственно быстрый. Плюс цена почти втрое меньше и принимают крипту.
Странно что при таких доходах, дропбокс не могут переписать свой клиент хоть с нуля.
robertd
Давно дропбокс не пользуюсь, но какие-то старые проекты и бэкапы там все еще лежат. Спасибо, что напомнили проверить