Pull to refresh
  • by relevance
  • by date
  • by rating

OmniDrive: храните ваши файлы удобно

Lumber room

Сервис OmniDrive, который впрочем никакого отношения к OmniGroup не имеет, представляет сервис для хранения ваших файлов. При регистрации вы выбираете тот тарифный план, которым будете пользоваться: Free, Pro1, Pro2, Pro3. Ознакомиться с ними можно на этой же странице sign up.

После логина вы видите интерфейс для работы с файлами. Ничего не напоминает? Правильно: до боли знакомый Windows смешанный с ajax. Даже иконки файлов взяты с Win, например для файлов jpg это иконки стандартного Просмотрщика изображений и факсов :).

Тут же замечаем, что часть места уже занята, но мы ничего еще не загружали! Парой кликов перейдя в папку Downloads понимаем, что там хранятся дистрибутивы клиентов: под Windows и Mac OS X. Клиента под Linux замечено не было, но забегая вперед, скажу, что под Mac OS X сервис монтируется как диск, поэтому под Linux наверняка найдется решение ;)

Я установила себе клиент под Mac OS X, и сразу скажу, что протестировать мне удалось только его. В связи с разного рода внешними факторами под Win у меня нет Интернета и протестировать там клиент мне не удалось. Сразу скажу: клиент на функциональность не богат. В нем даже настроек нет. Все, что от него требуется это залогиниться на сервисе, провести первичную синхронизацию, и подключить диск OmniDrive. Дальнейшая синхронизация может проводиться при выборе пункта контекстного меню на самом диске.

Отдельных слов заслуживает интерфейс в браузере. Тут естественно уже более богатый функционал. Функция загрузки файлов сделана таким образом, что после выбора одного файла, вы можете выбрать еще несколько и одним кликом загрузить их. Мои попытки сделать Advanced Upload потерпели поражение, ибо эта функция доступна только платным пользователям. Все файлы складываются в корневой каталог. Но при наличии функций copy&paste и возможности автоматической разархивации при загрузке все становится не так страшно :)

Отдельным пунктом нужно отметить функцию работы с Word-овскими и Excel документами, ибо продвинутый online-редактор от Zoho наличествует.

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

Выше я описала основные возможности сервиса OmniDrive, но помимо них есть например функция SlideShow по вашим изображениям, Live Folder, создание просто текстовых и html документов и др. Данный сервис мог бы быть очень полезен людям, которые много путешествуют и часто сталкиваются с документами, проще говоря — бизнесменам. Но студентам или людям, решившим перенести все свои .doc и .xls файлы в веб данный сервис очень бы пригодился. OmniDrive вполне достоин считаться конкурентом Google Docs & Spreadsheets.

Оригинал опубликован в блоге у Gluek тут.
Total votes 14: ↑6 and ↓8-2
Views224
Comments 5

Вышли Java/Python SDKs 1.4.3

Google App Engine
Files API: Теперь можно программно читать и писать в Blobstore. Доступно как в Python, так и в Java.
— Обновления в работе Task Queue и Cron: Для задач можно указывать версию приложения, с которой очередь будет работать, для крона аналогично + возможность указывать диапазон времени, например, «every 5 minutes from 11:00 to 17:00».

Для PythonSDK
Prospective Search API: Экспериментальное АПИ, позволяющее по критерию в момент вставки сущности в хранилище делать что-либо. Типа обратной связи по какому-либо критерию.
— Testbed Unit Test Framework: Тестирование для AppEngine, тут все должно быть и так понятно.

Для JavaSDK
Concurrent Requests: Теперь возможно использовать каждый инстанс может обстуживать мультипользовательские запросы в одно и тоже время, фича включается путем установки threadsafe в true в appengine-web.xml
— Remote API и Deferred API: Все по аналогии с PythonSDK.

Полные списки изменений:
Release Notes: Python
Release Notes: Java
Revision History
Product Roadmap
Total votes 29: ↑26 and ↓3+23
Views667
Comments 7

Материалы конференции DEF CON 1993-2013

Digital Security corporate blogInformation Security


DEF CON — крупнейшая в мире конференция хакеров, каждый год проводящаяся в Лас-Вегасе, штат Невада. Первый DEF CON прошёл в июне 1993 года.

Интересующимся информационной безопасностью, киберпанком, а также просто любым желающим — возможно, что вы упустили эту информацию. DEF CON выкладывают всю доступную информацию с самой первой конференции. Быстрые ссылки:

По ссылкам Вы сможете найти музыку, различное видео, записи выступлений, файлы с соревнований CTF, различный арт и многое, многое другое! Enjoy ;)
Читать дальше →
Total votes 53: ↑48 and ↓5+43
Views22K
Comments 4

Наиболее распространенные ошибки и заблуждения при настройке DFSR

System administrationIT InfrastructureServer optimizationServer AdministrationData storage
Translation
[Прим. переводчика. Материал статьи относится к Windows Server 2003/2003R2/2008/2008R2, но большинство из описанного справедливо и для более поздних версий ОС]

Всем привет! Уоррен снова здесь, и этот пост в блоге представляет собой подборку наиболее распространенных проблем DFSR, с которыми я столкнулся за последние несколько лет. Цель этого поста — перечислить распространенные ошибки в конфигурации DFSR, из-за которых возникают эти проблемы, и уберечь вас от совершения аналогичных ошибок. Знать, чего делать не следует, так же важно, как знать, что нужно делать. Многие из описанных пунктов связаны с другими темами, поэтому для углубленного изучения вопроса предоставлены соответствующие ссылки.
Читать дальше →
Total votes 11: ↑11 and ↓0+11
Views12K
Comments 0

MVCC-2. Слои, файлы, страницы

Postgres Professional corporate blogPostgreSQLSQL
В прошлый раз мы поговорили о согласованности данных, посмотрели на отличие между разными уровнями изоляции транзакций глазами пользователя и разобрались, почему это важно знать. Теперь мы начинаем изучать, как в PostgreSQL реализованы изоляция на основе снимков и механизм многоверсионности.

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

Отношения (relations)


Если заглянуть внутрь таблиц и индексов, то окажется, что они устроены схожим образом. И то, и другое — объекты базы, которые содержат некоторые данные, состоящие из строк.

То, что таблица состоит из строк, не вызывает сомнений; для индекса это менее очевидно. Тем не менее, представьте B-дерево: оно состоит из узлов, которые содержат индексированные значения и ссылки на другие узлы или на табличные строки. Вот эти узлы и можно считать индексными строками — фактически, так оно и есть.

На самом деле есть еще некоторое количество объектов, устроенных похожим образом: последовательности (по сути однострочные таблицы), материализованные представления (по сути таблицы, помнящие запрос). А еще есть обычные представления, которые сами по себе не хранят данные, но во всех остальных смыслах похожи на таблицы.

Все эти объекты в PostgreSQL называются общим словом отношение (по-английски relation). Слово крайне неудачное, потому что это термин из реляционной теории. Можно провести параллель между отношением и таблицей (представлением), но уж никак не между отношением и индексом. Но так уж сложилось: дают о себе знать академические корни PostgreSQL. Мне думается, что сначала так называли именно таблицы и представления, а остальное наросло со временем.
Читать дальше →
Total votes 36: ↑36 and ↓0+36
Views16K
Comments 18

MVCC in PostgreSQL-2. Forks, files, pages

Postgres Professional corporate blogPostgreSQLSQL
Translation
Last time we talked about data consistency, looked at the difference between levels of transaction isolation from the point of view of the user and figured out why this is important to know. Now we are starting to explore how PostgreSQL implements snapshot isolation and multiversion concurrency.

In this article, we will look at how data is physically laid out in files and pages. This takes us away from discussing isolation, but such a digression is necessary to understand what follows. We will need to figure out how the data storage is organized at a low level.

Relations


If you look inside tables and indexes, it turns out that they are organized in a similar way. Both are database objects that contain some data consisting of rows.

There is no doubt that a table consists of rows, but this is less obvious for an index. However, imagine a B-tree: it consists of nodes that contain indexed values and references to other nodes or table rows. It's these nodes that can be considered index rows, and in fact, they are.

Actually, a few more objects are organized in a similar way: sequences (essentially single-row tables) and materialized views (essentially, tables that remember the query). And there are also regular views, which do not store data themselves, but are in all other senses similar to tables.

All these objects in PostgreSQL are called the common word relation. This word is extremely improper because it is a term from the relational theory. You can draw a parallel between a relation and a table (view), but certainly not between a relation and an index. But it just so happened: the academic origin of PostgreSQL manifests itself. It seems to me that it's tables and views that were called so first, and the rest swelled over time.
Read more →
Total votes 7: ↑7 and ↓0+7
Views2.8K
Comments 0