как создать файловый менеджер самому на windows
|
|
Выпуск № 6   Как всегда, Вы можете отправить свои пожелания, кликнув по этой ссылке. Искренне Ваш. С уважением, Вахтуров Виктор. Пролог.  Как я писал в прошлой рассылке, сегодня мы начнем рассматривать новую тему.   Не будем долго думать в отношении того, какой же интерфейс у нас будет. Классический образ пользовательского интерфейса файлового менеджера существует уже давно (со времен первых версий Norton Commander). Потом он был воспроизведен во многих программах-оболочках, работающих под DOS и унаследован программами-файловыми менеджерами, работающими под Windows. Итак, «центром» всего интерфейса будут, как обычно, две панели, имеющие одинаковый внешний вид (содержащие списки файлов и директорий, а также некоторые элементы управления) и несущие одинаковую функциональную нагрузку. Сплиттеры.  Прежде чем начать создавать наш проект, позвольте изложить немного теории (ибо, куда же без нее, родной).   Наблюдая за развитием пользовательского интерфейса прикладных программ, работающих под управлением Windows, можно отметить явный прогресс в этой области за последние годы. Интерфейс действительно становится все более удобным и приятным, все более «дружественным». Все большую роль в этом процессе играют «неродные» Windows элементы управления, обладающие функциональностью, не реализованной в стандартных элементах и созданные разработчиками для решения специфических задач.   Если еще более пристально всмотреться в пользовательский интерфейс программ, использующих сплиттеры, то можно заметить, что не все сплиттеры одинаковы и, очевидно, у них разные принципы работы. Действительно, обычно различают два типа сплиттеров : дружественный и иерархический. Остановимся на каждом типе более подробно.   Вы можете увидеть такой вид сплиттера довольно часто. Ярким примером приложения, использующего именно дружественный сплиттер является приложение справочной системы Windows hh.exe.   На этом закончим лирическое отступление в область теории и приступим к практической работе.   Для начала создадим проект.   Теперь избавимся от этого окна, заменив его сплиттером.  1. Удалим строку объявления переменной m_wndView из декларации класса CMainFrame в header-файле MainFrm.h и добавим вместо нее переменную m_wndSplitter, объект класса CSplitterWnd.  2. Удалим из функции CMainFrame::OnCreate создание окна m_wndView. То есть удалим строки :  4. Добавим в класс CMainFrame еще две зашищенные (protected) переменные :  5. Добавим при помощи инструмента ClassWizard функцию OnCreateClient в класс CMainFrame, в которой добавим следующий код для создания сплиттера и дочерних окон :   // Код создания списков, добавления в них колонок и установки расширенных   return CFrameWnd::OnCreateClient(lpcs, pContext);  Ну вот, мы видим радостную картину : окно-рамка, панель инструментов (в своем первозданном состоянии), сплиттер, разделитель которого «прилеплен» к одному краю окна.   В следующей статье я расскажу о том, как доработать сплиттер MFC, добавив ему полезную функциональность.     А пока Все. Автор статьи : Вахтуров Виктор.   Исходный код проекта, рассматриваемого в статье вы можете найти на сайте рассылки SoftMaker.fatal.ru на главной странице проекта.   Дабы заранее разрешить возможные недоразумения, прошу Вас помнить, что Вопросы публикуются в рассылке только один раз. Поэтому, если Вам не ответили в этой рассылке, или ваш вопрос не был опубликован, пришлите его еще раз. Не стоит отвечать на вопрос, который был задан в предыдущей рассылке (за исключением случая, когда он снова опубликован в этой).   К сожалению, вопросов сегодня нет.   В данной рассылке нет ответов, так как не было задано вопросов в предыдущей. |
Всего доброго. До встречи в следующей рассылке.
Любой из материалов, опубликованных в этой рассылке, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.
Web файловый менеджер Sprut.IO в OpenSource
В Бегете мы долго и успешно занимаемся виртуальным хостингом, используем много OpenSource-решений, и теперь настало время поделиться с сообществом нашей разработкой: файловым менеджером Sprut.IO, который мы разрабатывали для наших пользователей и который используется у нас в панели управления. Приглашаем всех желающих присоединиться к его разработке. О том, как он разрабатывался и почему нас не устроили существующие аналоги, какие костыли технологии мы использовали и кому он может пригодиться, расскажем в этой статье.
Зачем изобретать свой файловый менеджер
В 2010 году мы использовали NetFTP, который вполне сносно решал задачи открыть/загрузить/подправить несколько файлов.
Однако, пользователям иногда хотелось научиться переносить сайты между хостингами или у нас между аккаунтами, но сайт был большой, а интернет у пользователей не самый хороший. В итоге, или мы делали это сами (что явно было быстрее), или объясняли, что такое SSH, MC, SCP и прочие страшные вещи.
Тогда у нас и появилась идея сделать WEB двух-панельный файловый менеджер, который работает на стороне сервера и может копировать между разными источниками на скорости сервера, а также, в котором будут: поиск по файлам и директориям, анализ занятого места (аналог ncdu), простая загрузка файлов, ну и много всего интересного. В общем, все то, что облегчило бы жизнь нашим пользователям и нам.
В мае 2013 мы выложили его в продакшн на нашем хостинге. В некоторых моментах получилось даже лучше, чем мы хотели изначально — для загрузки файлов и доступа к локальной файловой системе написали Java апплет, позволяющий выбрать файлы и все сразу скопировать на хостинг или наоборот с хостинга (куда копировать не так важно, он умел работать и с удаленным FTP и с домашней директорией пользователя, но, к сожалению, скоро браузеры не будут его поддерживать).
Прочитав на Хабре про аналог, мы решили выложить в OpenSource наш продукт, который получился, как нам кажется, отличным работающим и может принести пользу. На отделение его от нашей инфраструктуры и приведение к подобающему виду ушло еще девять месяцев. Перед новым 2016 годом мы выпустили Sprut.IO.
Как он работает
Делали для себя и использовали самые, по нашему мнению, новые, стильные, молодежные инструменты и технологии. Часто использовали то, что было уже для чего-то сделано.
Есть некоторая разница в реализации Sprut.IO и версии для нашего хостинга, обусловленная взаимодействием с нашей панелью. Для себя мы используем: полноценные очереди, MySQL, дополнительный сервер авторизации, который отвечает и за выбора конечного сервера, на котором располагается клиент, транспорт между нашими серверами по внутренней сети и так далее.
Sprut.IO состоит из нескольких логических компонентов:
1) web-морда,
2) nginx+tornado, принимающие все обращения из web,
3) конечные агенты, которые могут быть размещены как на одном, так и на многих серверах.
Фактически, добавив отдельный слой с авторизацией и выбором сервера, можно сделать мультисерверный файловый менеджер (как в нашей реализации). Все элементы логически можно поделить на две части: Frontend (ExtJS, nginx, tornado) и Backend (MessagePack Server, Sqlite, Redis).
Схема взаимодействия представлена ниже:
Frontend
Web интерфейс — все достаточно просто, ExtJS и много-много кода. Код писали на CoffeeScript. В первых версиях использовали LocalStorage для кеширования, но в итоге отказались, так как количество багов превышало пользу. Nginx используется для отдачи статики, JS кода и файлов через X-Accel-Redirect (подробно ниже). Остальное он просто проксирует в Tornado, который, в свою очередь, является своеобразным роутером, перенаправляя запросы в нужный Backend. Tornado хорошо масштабируется и, надеемся, мы выпилили все блокировки, которые сами же и наделали.
Backend
Backend состоит из нескольких демонов, которые, как водится, умеют принимать запросы из Frontend. Демоны располагаются на каждом конечном сервере и работают с локальной файловой системой, загружают файлы по FTP, выполняют аутентификацию и авторизацию, работают с SQLite (настройки редактора, доступы к FTP серверам пользователя).
Запросы в Backend отправляются двух видов: синхронные, которые выполняются относительно быстро (например, листинг файлов, чтение файла), и запросы на выполнение каких-либо долгих задач (загрузка файла на удаленный сервер, удаление файлов/директорий и т.п.).
Синхронные запросы — обычный RPC. В качестве способа сериализации данных используется msgpack, который хорошо зарекомендовал себя в плане скорости сериализации/десериализации данных и поддержки среди других языков. Также рассматривали python-специфичный rfoo и гугловский protobuf, но первый не подошел из-за привязки к python (и к его версиям), а protobuf, с его генераторами кода, нам показался избыточным, т.к. число удаленных процедур не измеряется десятками и сотнями и необходимости в выносе API в отдельные proto-файлы не было.
Запросы на выполнение долгих операций мы решили реализовать максимально просто: между Frontend и Backend есть общий Redis, в котором хранится выполняемый таск, его статус и любые другие данные. Для запуска задачи используется обычный синхронный RPC-запрос. Flow получается такой:
Интересные кейсы, которые стоит упомянуть
Загрузка файлов с Frontend
Задача:
Загрузить файл на конечный сервер, при этом Frontend не имеет доступа к файловой системе конечного сервера.
Решение:
Для передачи файлов msgpack-server не подходил, основная причина была в том, что пакет не мог быть передан побайтово, а только целиком (его надо сначала полностью загрузить в память и только потом уже сериализовывать и передавать, при большом размере файла будет OOM), в итоге решено было использовать отдельного демона для этого.
Процесс операции получился следующий:
Мы получаем файл от nginx, пишем его в сокет нашего демона с заголовком, где указано временное расположение файла. И после того, как файл полностью передан, отправляем запрос в RPC на перемещение файла в конечное расположение (уже к пользователю). Для работы с сокетом используем пакет pysendfile, сам сервер самописный на базе стандартной питоновской библиотеки asyncore
Определение кодировки
Задача:
Открыть файл на редактирование с определением кодировки, записать с учетом исходной кодировки.
Проблемы:
Если у пользователя некорректно распознавалась кодировка, то при внесении изменений в файл c последующей записью мы можем получить UnicodeDecodeError и изменения не будут записаны.
Все «костыли», которые в итоге были внесены, являются итогом работы по тикетам с файлами, полученными от пользователей, все «проблемные» файлы мы также используем для тестирования после внесенний изменений в код.
Решение:
Исследовав интернет в поисках данного решения, нашли библиотеку chardet. Данная библиотека, в свою очередь, является портом библиотеки uchardet от Mozilla. Она, например, используется в известном редакторе https://notepad-plus-plus.org
Протестировав ее на реальных примерах, мы поняли, что в реальности она может ошибаться. Вместо CP-1251 может выдаваться, например, «MacCyrillic» или «ISO-8859-7», а вместо UTF-8 может быть «ISO-8859-2» или частный случай «ascii».
Кроме этого, некоторые файлы на хостинге были utf-8, но содержали странные символы, то ли от редакторов, которые не умеют корректно работать с UTF, то ли еще откуда, специально для таких случаев также пришлось добавлять «костыли».
Параллельный поиск текста в файлах с учетом кодировки файла
Задача:
Организовать поиск текста в файлах с возможностью использования в имени «shell-style wildcards», то есть, например, ‘pupkin@*.com’ ‘$* = 42;’ и т.д.
Проблемы:
Пользователь вводит слово «Контакты» — поиск показывает, что нет файлов с данным текстом, а в реальности они есть, но на хостинге у нас встречается множество кодировок даже в рамках одного проекта. Поэтому поиск также должен учитывать это.
Несколько раз столкнулись с тем, что пользователи по ошибке могли вводить любые строки и выполнять несколько операций поиска на большом количестве папок, в дальнейшем это приводило к возрастанию нагрузки на серверах.
Решение:
Многозадачность организовали достаточно стандартно, используя модуль multiprocessing и две очереди (список всех файлов, список найденных файлов с искомыми вхождениями). Один воркер строит список файлов, а остальные, работая параллельно, разбирают его и осуществляют непосредственно поиск.
Искомую строку можно представить в виде регулярного выражения, используя пакет fnmatch. Ссылка на итоговую реализацию поиска.
Для решения проблемы с кодировками приведен пример кода с комментариями, там используется уже знакомый нам пакет chardet.
В итоговой реализации добавлена возможность выставить время выполнения в секундах (таймаут) — по умолчанию выбран 1 час. В самих процессах воркеров понижен приоритет выполнения для снижения нагрузки на диск и на процессор.
Распаковка и создание файловых архивов
Задача:
Дать пользователям возможность создавать архивы (доступны zip, tar.gz, bz2, tar) и распаковывать их (gz, tar.gz, tar, rar, zip, 7z)
Проблемы:
Мы встретили множество проблем с «реальными» архивами, это и имена файлов в кодировке cp866 (DOS), и обратные слеши в именах файлов (windows). Некоторые библиотеки (стандартная ZipFile python3, python-libarchive) не работали с русскими именами внутри архива. Некоторые реализации библиотек, в частности SevenZip, RarFile не умеют распаковывать пустые папки и файлы (в архивах с CMS они встречаются постоянно). Также пользователи всегда хотят видеть процесс выполнения операции, а как это сделать если не позволяет библиотека (например просто делается вызов extractall())?
Решение:
Библиотеки ZipFile, а также libarchive-python пришлось исправлять и подключать как отдельные пакеты к проекту. Для libarchive-python пришлось сделать форк библиотеки и адаптировать ее под python 3.
Создание файлов и папок с нулевым размером (баг замечен в библиотеках SevenZip и RarFile) пришлось делать отдельным циклом в самом начале по заголовкам файлов в архиве. По всем багам разработчикам отписали, как найдем время то отправим pull request им, судя по всему, исправлять они это сами не собираются.
Отдельно сделана обработка gzip сжатых файлов (для дампов sql и проч.), тут обошлось без костылей с помощью стандартной библиотеки.
Прогресс операции отслеживается с помощью вотчера на системный вызов IN_CREATE, используя библиотеку pyinotify. Работает, конечно, не очень точно (не всегда вотчер срабатывает, когда большая вложенность файлов, поэтому добавлен магический коэффициент 1.5), но задачу отобразить хоть что-то похожее для пользователей выполняет. Неплохое решение, учитывая, что нет возможности отследить это, не переписывая все библиотеки для архивов.
Повышенные требования к безопасности
Задача:
Не дать пользователю возможности получить доступ к конечному серверу
Проблемы:
Все знают, что на хостинговом сервере одновременно могут находиться сотни сайтов и пользователей. В первых версиях нашего продукта воркеры могли выполнять некоторые операции с root-привилегиями, в некоторых случаях теоретически (наверное) можно было получить доступ к чужим файлам, папкам, прочитать лишнее или что-то сломать.
Конкретные примеры, к сожалению, привести не можем, баги были, но сервер в целом они не затрагивали, да и являлись больше нашими ошибками, нежели дырой в безопасности. В любом случае, в рамках инфраструктуры хостинга есть средства снижения нагрузки и мониторинга, а в версии для OpenSource мы решили серьезно улучшить безопасность.
Решение:
Все операции были вынесены, в так называемые, workers (createFile, extractArchive, findText) и т.д. Каждый worker, прежде чем начать работать, выполняет PAM аутентификацию, а также setuid пользователя.
При этом все воркеры работают каждый в отдельном процессе и различаются лишь обертками (ждем или не ждем ответа). Поэтому, даже если сам алгоритм выполнения той или иной операции может содержать уязвимость, будет изоляция на уровне прав системы.
Архитектура приложения также не позволяет получить прямой доступ к файловой системе, например, через web-сервер. Данное решение позволяет достаточно эффективно учитывать нагрузку и мониторить активность пользователей на сервере любыми сторонними средствами.
Установка
Мы пошли по пути наименьшего сопротивления и вместо ручной установки подготовили образы Docker. Установка по сути выполняется несколькими командами:
run.sh проверит наличие образов, в случае если их нет скачает, и запустит 5 контейнеров с компонентами системы. Для обновления образов необходимо выполнить
Остановка и удаление образов соответственно выполняются через параметры stop и rm. Dockerfile сборки есть в коде проекта, сборка занимает 10-20 минут.
Как поднять окружение для разработки в ближайшее время напишем на сайте и в wiki на github.
Помогите нам сделать Sprut.IO лучше
Очевидных возможностей для дальнейшего улучшения файлового менеджера достаточно много.
Как наиболее полезные для пользователей, нам видятся:
Если у вас есть дополнения, что может быть полезно пользователям, расскажите нам о них в комментариях или в списке рассылки sprutio-ru@groups.google.com.
Мы начнем их реализовывать, но не побоюсь этого сказать: своими силами на это уйдут годы если не десятилетия. Поэтому, если вы хотите научиться умеете программировать, знаете Python и ExtJS и хотите получить опыт разработки в открытом проекте — приглашаем вас присоединиться к разработке Sprut.IO. Тем более, что за каждую реализованную фичу мы будем выплачивать вознаграждение, так как нам не придется реализовывать ее самим.
Список TODO и статус выполнения задач можно увидеть на сайте проекта в разделе TODO.
Спасибо за внимание! Если будет интересно, то с радостью напишем еще больше деталий про организацию проекта и ответим на ваши вопросы в комментариях.
Двухпанельный веб-файл менеджер Cloud Commander
Файловых менеджеров много, но есть один, о котором, думаю, будет многим интересно узнать. Ведь он двухпанельный, работает в браузере, оснащён редактором (с подсветкой синтаксиса) и консолью, состоит из клиента и сервера, а написан на JavaScript/Node.js.
Предисловие
Первая компьютерная книга, которую я прочитал была Windows: Лаборатория Мастера. Она рассказывает о разнообразных утилитах под Windows 9x. Некоторых из них уже не существует (Zip Magic 2000, например), другие же активно используются, и главное, разрабатываются по сей день (Total Commander). Больше всего мне понравился раздел про файловые менеджеры. Компьютера у меня еще не было, но уже тогда я понял, что использовать Проводник не серьёзно, и гораздо правильнее и удобнее пользоваться Двухпанельными файловыми менеджерами. Я перепробовал все, что были в книге за каждым компьютером, за которым мне удавалось побывать. Больше всего мне, конечно, понравился Total Commander. Он в своём деле лучший это бесспорно.
Через несколько лет, у меня появился компьютер. Спустя некоторое время, рядом с Windows я установил линукс, и хотел найти что-то подходящее для удобного управления файлами. У меня это не особо получилось. Да, Midnight Commander в *nix лучший, это правда. Но многих функций, к которым я так привык пользуясь Тоталом, в нём не было. Не было их и в графических менеджерах. Одна из таких функций, это перемещение указателя текущего файла во время ввода имени (когда папок очень много, а музыки у меня много — листать список, не самое приятное из занятий).
В итоге мне приятнее было слушать музыку, смотреть видео, и управлять файлами в голой консоли. На чем я и остановился на некоторое время.
Причины
Несколько лет спустя, устроившись в небольшую компанию, я понял, что попадать за свой компьютер буду значительно реже. И действительно, так сложились обстоятельства, что чаще я работаю за чужими компьютерами. А поскольку привыкать к новому мне не очень легко, я начал всё чаще использовать языки и средства разработки работающие в браузере и не требующие установки, настройки и прочих длительных вещей. Я начал использовать Cloud9, Koding и, конечно, GitHub.
Я загорелся идеей облачных сервисов, мне настолько понравилась открытость и возможности этих проектов, что я начал делать свой. Это файловый менеджер Cloud Commander.
Аналоги
Большинство аналогов написаны на php, который мне не особо близок. Большую часть кода я пишу на JavaScript, Поэтому, соответственно, мне хотелось бы видеть больше приложений написанных на языке, который быть может и не лучший, но самый распространённый, это точно.
Веб-файл менеджеры
Файловых менеджеров для веб очень много. Но, практически, у каждого из них есть несколько фундаментальных проблем:
Двухпанельные файловые менеджеры
Вменяемых двухпанельных файловых менеджеров, которые бы работали в браузере я как не мог найти 2 года назад, когда начал писать свою реализацию, так не могу найти сейчас. Хотя регулярно отслеживаю этот вопрос.
По началу у меня были идеи продолжить чьи-то начинания, подключиться к проекту, так сказать. Я нашел аналог (к сожалению ссылку уже не вспомню) total commander на SourceForge, с веб-интерфейсом, он был написан на PHP, с которым я в то время игрался. Весь его код был сложен в один файл, и разбираться с таким мне не особо хотелось. К тому же, в те времена, я начал активно интересоваться Node.js, и мне хотелось его попробовать на новом проекте.
Из интересного, что появилось с того времени, могу выделить разве, что Metro Commander. Правда пощупать его возможности нет, поскольку работает он лишь на win8, и не в браузере, а нативно. Но на скриншотах выглядит впечатляюще. В остальном в этом направлении особых движений нету, по крайней мере в местах где я ищу.
Особенности
И так, чем же таким интересным обладает Cloud Commander, что на него стоит обратить внимание? Разберём эти пункты подробнее поскольку это действительно важно.
Из самых интересных особенностей стоит выделить следующие:
Отличия
Главным отличием является двухпанельный интерфейс с привычными сочетаниями клавиш. Но это не всё. В противовес другим файловым менеджерам, работающим в браузере, Cloud Commander обладает консолью и редактором.
Редактор поддерживает подсветку синтаксиса больше 110 языков. Формат файла определяется по его расширению. Исходный код Cloud Commander правится в нём же самом (и эта статья пишется тоже в нём).
Консоль позволяет выполнять команды на сервере, и не важно это Linux, Mac OS или Windows. Сервер на котором запущен Cloud Commander управляется с консоли прямо в браузере.
Важным отличием также является Node.js как платформа, на которой работает Файловый Менеджер. Больше никакого php + apache.
Недостатки
Наличие преимуществ подразумевает также наличие недостатков, без этого никак. Самые существенные:
Это фундаментальные недостатки. Если говорить о насущных проблемах, то есть и такие. В редакторе:
Состав
Как уже было выше сказано, Cloud Commander состоит из клиента и сервера. О клиенте уже немного было сказано, поэтому начнём, наверно, с сервера.
Модули сервера
Сервер может работать без установленных зависимостей, при этом он переходит в режим ограниченного функционирования. В таком режиме не работает консоль, оптимизации js/css/html не выполняются, не работает копирование, перемещение и удаление папок. После установки модулей прописанных в package.json, используются:
Общие модули
Некоторые модули работают и на клиенте и на сервере, таким является diff-match-patch, разработанный давно, зато работающий очень стабильно.
Модули клиента
На клиенте список используемых модулей гораздо шире. Это:
Внутреннее устройство
Архиватор
Больше всего вопросов, наверно, вызывает архиватор на клиенте. Он используется для уменьшения размера данных отсылаемых на сервер редактором. Этот режим может быть включен (и выключен) в настройках. На самом деле, как я уже говорил, узкое место в клиент-серверном приложении — это передача данных. Запаковка (и распаковка на сервере), в свою очередь, выполняется чрезвычайно быстро.
Но текст не обязательно отправлять всегда целиком. Выгодно на сервер отправлять только те данные, которые поменялись, то есть патч. Поэтому, если, между правками, файл на сервере не менялся — отправляется патч и применяется на сервере (при условии, что файл весит не очень много, ведь каждая такая операция, это загрузка файла целиком в оперативную память), если менялся — отправляются сжатые данные. Благодаря этому скорость обработки данных очень близка к десктопному приложению.
Local Storage
Загружать данные с сервера тоже нет нужны при каждом открытии файлов. Поэтому, при открытии (файлы) кладутся в localStorage, в месте с sha-1 хешем. И, если хеш изменился (без нашего ведома), файл загружается снова, в другом случае хеш обновляется при каждом сохранении файла. Так же обстоят дела и с директориями. Если опция включена, содержимое директории загружается единожды, и для её обновления нужно нажать Ctrl + R (либо удалить/создать новый файл/папку).
Advanced Module Loading
В таком большом приложении с огромным количеством модулей, было бы очень сложно разобраться, если бы все файлы загружались сразу, при загрузке страницы. Такое приложение было бы сложно поддерживать, поскольку время-от-времени одни программы обновляются, а другие устаревают и требуют замены. Поэтому приложение разбито на модули: клиентские и серверные.
Клиентские модули загружаются по мере необходимости. Если человеку нужно меню — оно загружается, если за весь сеанс работы консоль так и не пригодилась — её файлы даже не загружались, и не начинали исполняться, что значительно увеличивает скорость работы, и экономит ресурсы как на клиенте, так и на сервере.
Потоки node.js — очень мощный инструмент, который кардинально отличается от того, что есть в других скриптовых языках. В процессе погружения в node.js меня не покидала мысль о том, что можно файлы объединять в поток, и отдавать так, как будто файл один. Я думал, что будут задержки в скорости, но нет. Всё работает как часы, и особых замедлений не ощущается, а вместо этого, появляется возможность не объединять файлы в один, и не загружать их последовательно, а загружать их как один файл.
Эту идею, с недавнего времени, начали продвигать в jsDelivr. И, мне кажется, это правильное направление.
Вкратце: если нужно загрузить файл jquery.js и jquery.fancybox.js, это можно сделать таким образом:
cloudcmd.jit.su/join/lib/jquery.js:lib/fancybox.js
С помощью символа «:» имена файлов отделяются друг-от-друга, таким образом, объединять можно абсолютно что угодно, и на быстродействие сервера это не должно особо влиять, поскольку файлы читаются последовательно, но сразу после чтения отдаются клиенту.
Если же прочитать файл не удаётся, вместо него отправляется сообщение об ошибке, после чего поток закрывается.
Разработка
О самом приложении сказано достаточно, но есть несколько вещей которые хотелось бы сказать о разработке. Как уже говорилось, Cloud Commander пишется в самом себе.
Проект хостится на гитхабе. В нём есть две ветки: dev и master.
В первой находится вариант, который разрабатывается, туда вносятся все правки, и хотя в идеале всё должно всегда работать, иногда случаются разные казусы.
Во-второй ветке находится последняя стабильная версия. Её всегда можно взять из репозитория, с ней всё должно быть нормально.
Непрерывная интеграция и тестирование
После каждого пуша, код отправляется в систему travis.ci, где запускаются прописанные тесты, а также код разворачивается на NodeJitsu и Heroku.
И если что-то работает не так как нужно, сразу приходит письмо, а также значок в репозитории меняет свой цвет на красный.
Если же на каком-то из сервисов Cloud Commander не отвечает, на сайте, в самом верху, возле ссылок отображаются не зеленые кружки, а красные. Если отвечает долго — желтые.
Task runner
На проекте используется Gulp, который автоматизирует все рутинные действия: проверяет js, css, запускает тесты и т.д.
Коммиты
Послесловие
Хочу поблагодарить читателя, за то, что дошел так далеко (даже, если он промотал просто). Надеюсь статья была полезной и интересной. Возможно будет продолжение, поживём — увидим.
Это моя первая статья на хабре, если есть опечатки, предложения, замечания — прошу в личку или в ветку hidden в репозитории. Буду стараться исправляться.