Да, в общем-то, такая же утилита вокруг http-модуля, написанная лишь для того, что бы Cloud Commander можно было запустить сразу после скачивания исходного кода. Это может быть полезно, например, в местах где нет интернета, но есть исходный код файлового менеджера.
Спасибо, действительно, символические ссылки и на windows, и на linux воспринимаются как обычные файлы,
в будущем думаю можно будет это изменить.
По-поводу смены диска на windows, это очень существенный пункт, я раздумываю как это сделать, но пока с этим трудности, в плане:
1. Интерфейса файлового менеджера
2. Изменения REST
Ведь диски есть только на windows, в linux, mac os, freebsd и т.д. их нет и отображать их смысла нету.
По-поводу кнопки настроек, да, это правда, была такая ошибка, я сегодня исправил, спасибо.
Если зависимости Cloud Commander'a не установлены, он будет работать без них, и в качестве веб-сервера будет использоваться велосипед, который работает похожим образом, на гораздо проще. Конечно, express, гораздо лучше, стабильнее и эффективнее во всех планах, но, при желании, без него можно и обойтись.
Во-первых, нет смены контекста, веб-разработчик может всё делать в браузере, не переключаясь между окнами и приложениями.
Во-вторых, поддержка Drag'n'Drop на уровне редактора и файлового менеджера и многие другие функции.
В-третьих, есть компьютеры, где нельзя устанавливать и запускать свои приложения, браузер, в свою очередь, есть везде.
А в целом, это не вытеснитель доступа по ssh, а взгляд с другой стороны.
Кроме недостатков есть достоинства, благодаря чему его вполне можно использовать как на локальном компьютере, так и на удаленном. Одно из реальных применений: разработка приложений. Как я уже говорил, Cloud Commander пишется в самом себе (и эта статья тоже была написана в нём), он запущен на удаленном компьютере, я могу к нему подключится с любого браузера. На работе я использую локально установленную версию, и пишу в ней код связанный с текущими проектами.
Я уже говорил об этом, но, на всякий случай, повторюсь (думаю, не все читают всю нить комментариев),
что подобная вещь под браузер существует. Это, конечно, не Фар. Но лучше многих аналогов.
У Deodar же, своя ниша, немного другая, но не менее нужная, как мне кажется.
В прочем, в будущем возможно появится возможность и в браузере Deodar запускать, но тут есть очень много подводных камней, поэтому, думаю, должно пройти какое-то время.
Думаю вам бы подошел веб файл менеджер для таких целей.
Вы могли бы поделится инструкцией сборки и разворачивания образов с cloud9? Или готовым образом?
По-поводу приложения, Деодар очень заинтересовал своим внешним видом и тем, что он написан на JavaScript/Node.js.
К сожалению завести его с первого раза не получилось.
Буду рад, если автор мне поможет с этим.
А вообще очень интересный проект, надеюсь автор не утратит энтузиазм, и будет продолжать улучшать приложение и упрощать его установку. Ожидайте пул риквестов ;).
Разница в том, что:
1) В момент вызова fs.closeSync вся программа ждёт её завершения, и новые файлы не открываються, и сервер ничего не обрабатывает, полное замирание, в случае же с ассинхронной версией, файл закроеться когда закроеться, это не так важно, на самом деле, за то новые файлы смогут открываться и закрываться и новые соединения будут работать, всё будет заметно быстрее работать.
Мне кажеться проблема изначально была в том, что используеться синхронная версия fs.close ведь она блокирует всё приложение, что бы просто закрыть файл.
Поскольку статус операции всё-равно не проверяеться (да и каким он, в принципе может быть?), думаю, использование асинхронной функции закрытия файла решило бы проблему без необходимости использования сторонних библиотек.
Для чего использовалась именно синхронная версия функции fs.close?
в будущем думаю можно будет это изменить.
По-поводу смены диска на windows, это очень существенный пункт, я раздумываю как это сделать, но пока с этим трудности, в плане:
1. Интерфейса файлового менеджера
2. Изменения REST
Ведь диски есть только на windows, в linux, mac os, freebsd и т.д. их нет и отображать их смысла нету.
По-поводу кнопки настроек, да, это правда, была такая ошибка, я сегодня исправил, спасибо.
Во-вторых, поддержка Drag'n'Drop на уровне редактора и файлового менеджера и многие другие функции.
В-третьих, есть компьютеры, где нельзя устанавливать и запускать свои приложения, браузер, в свою очередь, есть везде.
А в целом, это не вытеснитель доступа по ssh, а взгляд с другой стороны.
Преимущества: открытый исходный код, имеет встроенный редактор/просмотрщик и консоль, а главное — он работает в браузере почти всех девайсов.
что подобная вещь под браузер существует. Это, конечно, не Фар. Но лучше многих аналогов.
У Deodar же, своя ниша, немного другая, но не менее нужная, как мне кажется.
В прочем, в будущем возможно появится возможность и в браузере Deodar запускать, но тут есть очень много подводных камней, поэтому, думаю, должно пройти какое-то время.
Вы могли бы поделится инструкцией сборки и разворачивания образов с cloud9? Или готовым образом?
По-поводу приложения, Деодар очень заинтересовал своим внешним видом и тем, что он написан на JavaScript/Node.js.
К сожалению завести его с первого раза не получилось.
Буду рад, если автор мне поможет с этим.
А вообще очень интересный проект, надеюсь автор не утратит энтузиазм, и будет продолжать улучшать приложение и упрощать его установку. Ожидайте пул риквестов ;).
программа просто упадет, а во второй
стоит проверить результат операции закрытия файла.
1) В момент вызова fs.closeSync вся программа ждёт её завершения, и новые файлы не открываються, и сервер ничего не обрабатывает, полное замирание, в случае же с ассинхронной версией, файл закроеться когда закроеться, это не так важно, на самом деле, за то новые файлы смогут открываться и закрываться и новые соединения будут работать, всё будет заметно быстрее работать.
2) callback можно вызывать сразу и ничего страшного не произойдёт, дожидаться закрытия файла не обязательно, НО, если это ВАЖНО, то это всё таки будет лучше асинхронная версия поскольку программа не будет «замирать» ожидая пока файл закроеться.
habrahabr.ru/post/150788/
nodemanual.org/latest/nodejs_dev_guide/writing_asynchronous_code.html
habrahabr.ru/post/128772/
Райан Дал очень хорошо рассказывает о разнице между блокирующими и не блокирующими операцияи в каждом интервью, а особенно в этом ролике www.youtube.com/watch?v=jo_B4LTHi3I
Поскольку статус операции всё-равно не проверяеться (да и каким он, в принципе может быть?), думаю, использование асинхронной функции закрытия файла решило бы проблему без необходимости использования сторонних библиотек.
Для чего использовалась именно синхронная версия функции fs.close?