Бизнес в облаке

ессэсно, я - про то, что мозг человеческий - инертен, равно, и как бизпроцессы... вот закрыл, а... А-а-а-а...

а нету уже

Ну вы блин конспираторы...
А может ну его нафиг всё это: и отстроите бизнес так, чтобы все налоги тютелька в тютельку платить, без излишеств?
А то как говорил один мой дааааавний знакомый: "у меня за ночь, 5 человек в камере признались что пытались на прошлой недели Обское море поджечь". К тому что кто-то да сольет ваши тайны. Испугается, запугают, побьют и пр.

В ответ на: Когда я тебе делал обмен, я ведь мог тупо сделать то что тебе было надо, не добавляя выбор базы из списка, не делая проверку уже загруженных документов и т.п. И тебя бы это устроило, ты бы спокойно дальше работал. Но ты же оценил мои старания. Для меня решение задачи - это не только чтобы тупо работало, но и чтобы этим было легко и удобно пользоваться. Вот и все.

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

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

В ответ на: Кирилл, ты реально не представляешь разницы между полноценным мессенджером, с адресной книгой, каналами, передачей файлов и тд. и т.п. и твоим велосипедом? Ну тогда извини, у меня нет слов.

Здесь не только не нужны функции полноценного мессенджера, они еще и вредны тут. Фирмы должны быть полностью независимы, сотрудники желательно не должны знать друг друга вообще. Лишняя переписка между ними вредна.

В ответ на: Восстановление идет по кластерам, с контекстным поиском по базе ключевых слов. Делается это все автоматически, так что не важно где и как хранился текст.

Вово. Когда в чате адресные книги и переписка типа "Привет, как дела" ее легко найти контекстным поиском. А когда там только секретный пароль от инет-банка передается? Как его найти? Потому и не нужны вот эти все прилады для болталки. Чтобы у людей ни желания ни возможностей не было обмениваться какой-то произвольной инфой по этому каналу.

В ответ на: Никакой это не кейс, и даже не решение. Колхоз чистой воды.

Ну да. Теперь объясни мне почему мое решение колхоз, а твоя допилка Джаббера не колхоз? А? Манипулятор ))))

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

Хорошее решение. С точки зрения надежности едва ли не лучшее ибо end-to-end шифрование. Но опять же с точки зрения применимости в бизнесе...

В ответ на: 3. Сообщаем остальным участникам свою уникальную строку любым способом. Можно заранее договориться

Ты это так промеж делом написал. А на самом деле это один из самых геморов. Ладно сначала, собрали всех, выдали. А потом? Уволился у тебя чувак в Мск, надо сменить секретную фразу. Как ее довести до всех участников, часть которых за границей? Еще один секретный канал городить для передачи секретных фраз?

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

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

Так и есть. Потому и отвергли это решение.

В ответ на: ессэсно, я - про то, что мозг человеческий - инертен, равно, и как бизпроцессы... вот закрыл, а... А-а-а-а...

Именно. Поэтому это не болталка, а канал согласования сделок. Получил нужную инфу и закрыл

А вся хозяйственная инфа ходит по открытым каналам. Но благодаря правильному реинжинирингу бизнес-процессов, не ходит туда куда не надо.

В ответ на: Ну вы блин конспираторы...
А может ну его нафиг всё это: и отстроите бизнес так, чтобы все налоги тютелька в тютельку платить, без излишеств?
А то как говорил один мой дааааавний знакомый: "у меня за ночь, 5 человек в камере признались что пытались на прошлой недели Обское море поджечь". К тому что кто-то да сольет ваши тайны. Испугается, запугают, побьют и пр.

Именно. У меня есть клиент, который как мантру повторяет "база упручета должна лежать на секретном сервере..." и так далее. При этом у него "черный" нал экспедиторы в открытую сдают ежедневно в кассу, а главбух ведет "дополнительную кассу" в общей же 1С.

Никому нах в таком раскладе база не нужна.

В ответ на: Ты это так промеж делом написал. А на самом деле это один из самых геморов. Ладно сначала, собрали всех, выдали. А потом?

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

Но, видимо, мы по разному понимаем решение этой задачи. Раз твоих клиентов устроил твой вариант - значит все нормально. О чем тут спорить?

В ответ на: Почему не договориться, что кодовым словом является, например, 10-е слово в той самой спам-рассылке? Чтобы оповестить - ты же рассылаешь эту рассылку, так вот это и будет оповещением о необходимости встретиться в чате, а пароль - нужное слово в тексте рекламы.
В чем проблема-то?

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

В ответ на: ИМХО, вы, ребята, занимаетесь изобретением ручки для письма

Так об этом и говорилось уже много раз. Но сейчас обсуждается не необходимость этого, а конкретное решение, не более того

В ответ на: ИМХО, вы, ребята, занимаетесь изобретением ручки для письма в невесомости за миллион, хотя давно изобретен простой карандаш за три копейки.

Я тут еще одну ручку начал изобретать

Но зато с помощью Agile

Так же можно?

Прям то, что я целюсь сделать в следующем году.

И я давно искренне считаю, что ЦРМ крайне опасно покупать в готовом коробочном решении. Сколько мне всяких предлагали - ни одна не подходит достаточно хорошо и полноценно. И ведь это не туфли новые, которые разносятся - тут либо всегда будут кровавые мозоли, либо переделывать под себя. Так уж лучше я сам приложусь хорошенько, чтобы сразу было хорошо + допиливаемо в процессе минимальными средствами.

Уже год пользуюсь гугл таблицами, можно сказать что опыт уже есть. Ну что сказать - в целом НЕ нравиться.

1. Постоянно какие то непонятки со стабильностью работы. То что иногда работает неделями, может в какой-то день не сработать, как обычно. И причины НЕПОНЯТНЫ. Решалось тупо повторным запуском образно говоря скрипта по новой и он выполнялся!!!!. Почему не не выполнился как нужно, скажем 10 минут назад - загадка. Если вопрос в падении производительности из-за роста объема таблиц, то тут вообще хохма, почти неделю ничего толком не работало, каждый день в ручном режиме запускал повторно скрипты, пытаясь с помощью. матерых консультантов разобраться с проблемой. Никто ничем толком не помог, я уже психанул и забил, и тут просто не с того ни с сего все заработало и проработало ровно неделю. Сейчас опять время от времени подглючивает. Но гораздо реже.

2. Огромный плюс, который, как мне казалось, перекроет все неудобства работы - это то, что почти с любого устройства и с любой точки земного шара можно работать с таблицами оказался фейком. Система тормознутая, на смартфоне не особо удобно смотрибельная. С большими данными работать неудобно.

3. Захотелось вернуться на старый и добрый ексель, при этом перенести в него нужный функционал.

Вот как то так(

Так, вроде, все проблемы - стандартны, при использовании не своего ПО не на своем оборудовании?
Что б далеко не ходить - как форум плющит периодически? И какие глюки вдруг на ровном месте возникают...

Если бы это был какой то нгс, то еще ладно, а тут великий ГУГЛ. Вообщем странно.

На смартфоне чтобы посмотреть таблицу - можно ждать минуту ее открытия, просто открытия. Что то в нее вносить-исправлять - это нереально. Это в вай-фае. Хотя иногда в 4джи вроде открываться за 10 секунд. На обычном компе, с хорошим интернетом, еще как то можно табличку править, в час по чайной ложке. Но тоже тормознутое все.

Вообщем инструмент для таблицы из 100 строк, я такой для себя сделал вывод( Интересен только функционал многопользовательского изменения разными людьми одной и той же таблицы, с правами доступа. Но мне это ни к чему(

Странно еще вот что- на форуме матерых разработчиков треться что-то про великие задачи, которые они решают. Но как что то можно доверить этому инструменту, что то крайне оперативное? Ладно кассу не смогли закрыть вечером, неприятно, но не смертельно, закроют зватра, когда в гугле что-то все таки заработает как должгно работать утром). А если это что то требующее мгновенной он лайн реакции, типа выписать счет клиенту, который стоит над душой или что то вроде этого?

Кто нибудь решал для себя автоматизацию кассы многофилиальной структуры? Задача - в каждой точке вести таблицу типа - остаток на начало, строки прихода и расхода денежный средств, остаток на конец дня. Ну и некоторые доп поля с примечаниями

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

Зря ты так про декретниц. Вот столько сообществ по совместным покупкам в Вконтакте. Не учитывались сообщества <100 участников. Девчули не на шутки разошлись, +120 млн выложенных фотографий

ну вот они значит все сервера и вешают
не в том суть
dvv изначально решения в этом вопросе ищет не там, судя по сообщениям

В ответ на: Странно еще вот что- на форуме матерых разработчиков треться что-то про великие задачи, которые они решают. Но как что то можно доверить этому инструменту, что то крайне оперативное?

Вов, ну ты ж видел, там 63 человека. У 62 все работает ))))

И еще некоторые то ведь программят не для себя а для клиентов, то есть количество работающих проектов больше )))

Ну так я и высказал свое мнение. А то, там все может меряются одним местом, и это может еще не говорит, что где то что то успешно работает. Вот ты бы и расказал, где и что работает успешно. Какие примерно системы автоматизации сделаны на базе этого. Тебе все равно спасибо, что погрузил во все это.

Для ведения некой таблички из 100 записей это работает. 10т запись оно даже открывает то с трудом для просмотра, не говоря уже о том что с этим как то работать можно.

В ответ на: А то, там все может меряются одним местом, и это может еще не говорит, что где то что то успешно работает.

Вов, мы специально этот чат создали чтобы заманивать неокрепшие умы Все там все врут

В ответ на: Вот ты бы и расказал, где и что работает успешно. Какие примерно системы автоматизации сделаны на базе этого. Тебе все равно спасибо, что погрузил во все это.

Ну так я все в блоге рассказываю. Это все ежедневно у меня работает. Все что опубликовал все работает.

В ответ на: Для ведения некой таблички из 100 записей это работает. 10т запись оно даже открывает то с трудом для просмотра, не говоря уже о том что с этим как то работать можно.

Я себе для ИП веду учет в облачной Таблице. Завожу Таблицу на год. Сейчас посмотрел, за прошлый год 1014 записей. Это только реестр операций. Еще лист со справочниками и 7 листов с отчетами, полных формулами. Только лист "остатки" это еще 365 строк и шесть колонок, в каждой ячейке формула многофакторного суммирования. Того, о чем ты говоришь в помине нет.

В ответ на: Сейчас посмотрел, за прошлый год 1014 записей.

Да, разочаровался я что-то, 1014 записей это ни о чем, это даже офигенски ни о чем.

Профессиональные БД типа paradox, interbase, access и то где-то на 100 Mb тупить начинают, а это десятки тысяч записей (у меня как правило в таблице протокол) и производители их чистить рекомендуют.

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

Зато офигенски круто сравнивать между собой электронные таблицы и СУБД. Это примерно как назвать Феррари хреновой тачкой, потому что на ней на поребрик не заедешь

Феррари - хреновая тачка, это я , как сибиряк говорю
Вова, если б гугл-таблицы работали, их бы продавали, а не раздавали для бета-тестирования

вот именно такое мнение у меня и сложилось, к сожалению.

Кирилл, я специально в этом топике и написал свой личный опыт. Ведь топик же для этого создан - для обсуждения. И будет хорошо тут мнение реально потребителя услышать, а не только разработчиков. Для чего то маленького не вопрос - подойдет. Для более-менее среднего - дикие тормоза. Наверное, когда у меня было в районе 1000 записей - все более-менее работало. Подозреваю, что проблемы начались после перешагивания какого то предела.

Я уже года три пользуюсь этими таблицами. Всё ок. Данных много, в общем по строкам тысяч 30 точно наберётся. Разграничение доступа, авторизация, все дела. Ещё и ссылками некоторые записи идут, чтобы по наименованию проекта перенаправить на проектную документацию, хранящуюся также на Гуглдиске. Единственный минус - ГуглХром насасывается оперативки до упора, но это не проблема.

Так мне сдается лучше заранее сравнить, с некоторой долей драматизации правда, чем потом в темпе вальса за нехилые бабосы (for the speed) информационную составляющую бизнеса переделывать.

30т есть в одной таблице? Или размазано в разных таблицах? У меня основная около 13т, таблица открывается от 10секунд до минуты. В плане не просто открыть ее - а с позиционировать курсор к примеру на конец таблицы. Пользуюсь мозилой. Процессор грузиться мама не горюй. И это для по сути для тонкого клиента, который лезет в облако. Не правда ли странно?

Ну и больше всего напрягает нестабильность. Один и от же скрипт может выполниться,а может зависнуть на нес суток и так и не выполниться до конца. Сначала подумал построить скрипт с учетом неопределенности работы гугл таблиц - предусмотреть что в нем может что-то не так сработать, и предусмотреть повторные запуск скрипта со всевоможными проверкамми результатов первичного запуска. Но пока руки не дошли( Да и сомневаюсь я, что он переживет поиски в 13т таблице(

В ответ на: Кирилл, я специально в этом топике и написал свой личный опыт. Ведь топик же для этого создан - для обсуждения. И будет хорошо тут мнение реально потребителя услышать, а не только разработчиков.

Так я и есть потребитель

В ответ на: Для чего то маленького не вопрос - подойдет. Для более-менее среднего - дикие тормоза. Наверное, когда у меня было в районе 1000 записей - все более-менее работало. Подозреваю, что проблемы начались после перешагивания какого то предела.

Ну я тебе так могу сказать: ты (и я и еще многие) пытаешься использовать электронную таблицу как базу данных. И здесь есть некий предел у этого инструмента, независимо Эксель это или ГуглТаблицы. То есть, если Эксель тянет, то и Таблицы будут тянуть.

Мое мнение - тебе еще далеко до этого предела. Ты просто неверно организуешь работу свою. Я тебе уже про это говорил, но ты рукой махнул.

Надо разделять функции хранения (функция БД) и представления данных (фнукция эл. таблиц). Ты все на один лист забабашил, даже остатки. С таким единым листом у тебя и Эксель не так быстро бы летал ИМХО.

Есть лист реестр, есть отчетные листы. Смотреть надо их, с реестром операционной работы должно быть по минимуму. А у тебя основная работа елозить 30тысячный лист - ну да, конечно у тебя все подвиснет.

В ответ на: Да и сомневаюсь я, что он переживет поиски в 13т таблице(

Поиск это, кстати, конек Гугла
У них в акке очень крутой поиск. За это не переживай.

С точки зрения технической реализации самой таблицы на серваке нет. Ячейки хранятся по раздельности. Поэтому поиск от размера таблицы не зависит особо.

В ответ на: Надо разделять функции хранения (функция БД) и представления данных (фнукция эл. таблиц). Ты все на один лист забабашил, даже остатки. С таким единым листом у тебя и Эксель не так быстро бы летал ИМХО.

Поддерживаю.

Кстати, сегодня ради эксперимента взял одну из таблиц в экселе, засёк время поиска по слову - около 25 секунд по 137 450 строкам и 10 столбцам, то есть по 1 млн 374 тыс ячеек.

1. потребитель и разработчик в одном лице, а это иной раз мешает объективности

2. Насчет неверной организации данных- это не смешно - парочка лишне-избыточных колонок (не связанных никакими связями с другими таблицами) явно не должны мешать простецкому алгоритму - просканировать строки (максимум 10 штук) в одной таблице (заведомо указав откуда до куда без всяких поисков) и тупо доабавить эти строки в другую таблицу (в которой 10т записей), строка в строку, колонка в колонку - не должно создать затруднений. А также просто открыть эту самую большую таблицу и по ней позиционироваться из начала в конец. Наоборот, "нормализация" структуры данных всегда приводит к некому замедлению работы, естественно получая выигрыш в объеме хранения избыточных данных, если конечно таблица не содержит в себе какие то индексные файлы, как в базе данных. В гугл таблицах думаю даже этим не пахнет. Так вот я говорю, что хранения данных в облаке более 10т записей в одной таблице из 6-7 колонок - это утопия. Работает конечно, но хочется иной раз выкинуть все это за окно). Есть конечно у меня подозрение на лист с кучей формул для расчета остатков (это как раз та нормализация), но ты сам сказал, вряд ли они могут быть источником тормоза, а я уже в алгоритме к ним привязался. Можно конечно попробовать передать и обойтись совсем без них (как раз путем упрощения таблиц в ущерб нормализации данных) - но блин нету уверенности, что это поможет.

3. Ексель позиционируется на 10т записях почти мгновенно, но это и понятно - данные хранятся на локальном быстром диске.

4. Алексей ты не ответил на вопрос - у тебя 30т записей в одной табличке? или разнесены по разным? Разницу понимаешь? В любой клиент-серверной организации доступа к данным противопоказаны просмотры ВСЕЙ таблицы, если в таблице много записей - так как слишком большие запросы идут и большие ответы на запросы по сети. Там как правило делается некий поиск по ключу. Это типа того что дать список всех абонетов сети МТС в РФ в виде таблицы - будет грузиться долго. Обычно делают запрос - например, конкретное ФИО или другие параметры выборки.

4. глюки работы гула появились задолго до моих избыточных полей,избыточные поля хотя бы позволили мне отматывать ситуацию назад и разбираться, ибо глюк приводил по сути к неадекватности данных - а это касса(

Кирилл, при все уважении, ты читаешь нотации бывшему программисту и специалисту по базам данных - начиная от FoxBase заканчивая Oracle. Уж законы нормализации и оптимизации баз данных я знаю хорошо.

В ответ на: 1. потребитель и разработчик в одном лице, а это иной раз мешает объективности

Здесь же вопрос цены использования. Вот если бы я себе платил за все разработки - то да. А так мне бы эти все тормоза как и тебе в копеечку влетали бы. И смысл мне тогда в этой необъективности? Я ж на этом не зарабатываю

В ответ на: 2. Насчет неверной организации данных- это не смешно - парочка лишне-избыточных колонок (не связанных никакими связями с другими таблицами) явно не должны мешать простецкому алгоритму - просканировать строки (максимум 10 штук) в одной таблице (заведомо указав откуда до куда без всяких поисков) и тупо доабавить эти строки в другую таблицу (в которой 10т записей), строка в строку, колонка в колонку - не должно создать затруднений.

Алгоритму перелива, безусловно, не должно мешать. Я и не претендую на этот тезис. Зависание алгоритма ИМХО происходит из какой-то алгоритмической ошибки. Ее просто надо было отыскать. Скрупулезно, кропотливо, с разных компов... Но это времени много.

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

А вот на это тезис я претендую. Ты представь, это же не клиентское приложение отображения данных. Это браузер !!! То есть, он мало того, что должен данные получить, он еще и должен из них страницу сверстать с форматированием в виде эл. таблицы. И именно в этот момент (отображения) у тебя все видимые формулы и пересчитываются. И абсолютно неважно уже становится нормализованы или нет были данные, когда хранились где-то там. Это все равно слишком тяжело для браузера.

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

Ну как же? Если Таблицы позволяют делать SQL-запросы, то это именно этим и воняет.

В ответ на: Так вот я говорю, что хранения данных в облаке более 10т записей в одной таблице из 6-7 колонок - это утопия. Работает конечно, но хочется иной раз выкинуть все это за окно).

Ну я тебе еще раз повторю. Если делать на одном листе и просмотр и редактирование и хранение - я согласен, работать не будет. Покупай программу кассовую или пиши сам программу для базы данных и работай. В чем проблема?

В ответ на: Есть конечно у меня подозрение на лист с кучей формул для расчета остатков (это как раз та нормализация), но ты сам сказал, вряд ли они могут быть источником тормоза, а я уже в алгоритме к ним привязался. Можно конечно попробовать передать и обойтись совсем без них (как раз путем упрощения таблиц в ущерб нормализации данных) - но блин нету уверенности, что это поможет.

Ты вот постоянно путаешь эти два момента. Ошибку в алгоритме переливки и тормоза при скроле перемешанного листа. Я тебе говорил что для алгоритма они не могут быть источником тормоза. А на листание они прямое влияние оказывают.

В ответ на: 3. Ексель позиционируется на 10т записях почти мгновенно, но это и понятно - данные хранятся на локальном быстром диске.

Бинго!!! Но у тебя же не было единого листа на все точки с такими формулами? У тебя ж на каждую точку свой лист был?

В ответ на: Кирилл, при все уважении, ты читаешь нотации бывшему программисту и специалисту по базам данных - начиная от FoxBase заканчивая Oracle. Уж законы нормализации и оптимизации баз данных я знаю хорошо.

А я про законы нормализации и оптимизации баз данных вообще не спорю. Я их даже не знаю вообще. Они тут никакой роли не играют. )))))

Ладно, почти со все соглашусь с натяжкой, кроме - "надо было кропотливо найти эту ошибку". Ошибка это когда она постоянно вылазит, или хотя бы есть какая то логика ее появления. Тут просто неопределенность(

Выгядит так, что сервер гугл просто внезапно отказывает в чтении/записи данных в любой из возможных моментов. Путь исправления этой досадной ситуации только один - строить более умный алгоритм, с поисками и проверками - на каком этапе изменения данных отвалился предыдущий запрос, и с учетом этого ДОДЕЛЫВАТЬ его. Попробовал разобраться с этим на скоряк - не вышло( Спецы в чате тоже занятые. Чат кстати ужасно неудобный(

В ответ на: "надо было кропотливо найти эту ошибку". Ошибка это когда она постоянно вылазит, или хотя бы есть какая то логика ее появления. Тут просто неопределенность(

Вов, тут просто иная идеология программирования. Для меня это тоже ново потому что я тоже начинал программировать еще на Фортране и Ассемблере. А это Инет-программирование.

Вот тебе пример, почему так может быть. У меня такое было.

Я с Таблицей работал через объект SpreadsheetApp, причем каждую операцию! А несмотря на то, что она указана обычной командой, это вызов API Таблицы и работает очень долго. Правильно надо одним вызовом вытащить нужный диапазон в массив и работать уже с ним. Потом новый массив залить в Таблицу.

Как это влияет на программу? Вызовы API это обращения на сервер Гугл в общем порядке, то есть твои команды перемешиваются, например, с моими и Лешиными. Гугл их как то ставит в очередь, вешает когда их слишком много, разводит как-то сам. У меня даже было что более поздний вызов выполнился раньше. Из-за этого нарушалась логика исполнения программы.

Во-вторых, есть лимит на выполнение скрипта - 6 минут по-моему. Из-за этих подвешенных АПИ ты можешь просто за лимит выскочить, тогда твой скрипт просто остановится и все.

Ты же программируешь "как на Oracle" и эту всю апишную и облачную механику не вкуриваешь (я сам ее очень долго не вкуривал).

В ответ на: Выгядит так, что сервер гугл просто внезапно отказывает в чтении/записи данных в любой из возможных моментов. Путь исправления этой досадной ситуации только один - строить более умный алгоритм, с поисками и проверками - на каком этапе изменения данных отвалился предыдущий запрос, и с учетом этого ДОДЕЛЫВАТЬ его.

Так и есть. Только доделывать предварительно разобравшись в механике работы.

В ответ на: Спецы в чате тоже занятые. Чат кстати ужасно неудобный(

Неудобный - да. Спецы занятые - да. Но Иванов бы тебе помог бы. Если бы ты выложил код куда-нибудь. Есть же специальные ресурсы. Мне он всегда писал даже больше чем я от него ожидал.

Просто инфу надо в более удобном для человека (который тебе бесплатно хочет помочь) виде предоставлять. А не в чат листинги сыпать

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

В ответ на: ну блин, тогда надо изучать все тонкости команд, вкупе с их производительностью.

Не, достаточно архитектуру понять. Что где хранится, что где выполняется

Всем привет.

Excel позволяет групповую работу с таблицами, и удаленный доступ, и разграничение полномочий и пр.
Так же, Excel легко ставится на смартфоны, планшеты и пр.

Вопрос в связи с этим. Чем лучше Гугл таблицы?
P.S. Сам то я пользуюсь, но только потому что так было принято в проекте "до меня".

В ответ на: Вопрос в связи с этим. Чем лучше Гугл таблицы?

Смотри

1) Берешь таблицу Эксель. Одновременно с коллегой ее открываете (групповая же работа доступна, так ведь). Начинаете вносить данные. Ты в колонку А, твой коллега в колонку В. Два часа вносите. Обращаю внимание, что все это время данные твоего коллеги в твоей таблице будут не видны, как и твои в его таблице. Через два часа пытаетесь сохранить данные. Получаете окно "Файл занят другим пользователем". Созваниваетесь с коллегой и решаете кто первый выйдет без сохранения. Потом перебиваете заново потерянный столбец с мыслью "лучше бы в Гугл Таблицах работали".

ПыСы: программисты тут со временем ничего не исправят. Эксель заложник операционной системы, в которой он работает, которая умеет сохранять только файлы. Она не может в файл одну только клетку записать, только файл целиком. В то время как в облаке Гугл клетки хранятся по отдельности и объединяются в таблицу только в окне браузера. Поэтому Гугл Таблицы дают возможность НАСТОЯЩЕЙ групповой работы (внося свои данные ты мгновенно будешь видеть данные, вносимые твоим коллегой), а Эксель максимум что может предоставить - ОДИН редактирует, ОСТАЛЬНЫЕ смотрят (и то, для этого тому одному надо периодически сохранятся)

2) Ну и вот есть у тебя таблица Эксель. Хочешь ты меня туда подключить чтобы я мог хотя бы смотреть. Что мне тебе надо дать, чтобы ты меня подключил? ФИО, паспортные данные, прописку, емейл, сотовый телефон? Что? Подключи ка.

3) Ну и как бы я не уверен что Эксель схожие возможности предоставляет по разграничению доступа вплоть до ячейки как Гугл Таблицы опять же в связи с тем, что Эксель оперирует файлами, а Гугл клетками. Но я с Экселем давно не работал, мож тут что-то придумали. ХЗ

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

Но плата за это - скорость

Да отличный инструмент для определенных задач. Но следует учитывать ограничения по лимиту - 2млн ячеек, а также скорость сети скачивания /загрузки. Иногда она не выше 10 мбит/сек. Даже не очень тяжелые файлы иногда грузятся несколько минут. Зависит от формул.

В ответ на: Эксель заложник операционной системы, в которой он работает, которая умеет сохранять только файлы. Она не может в файл одну только клетку записать, только файл целиком.

Вот тут бред.

Ну бред так бред

Так на нем тот длинный постулат весь был построен?

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

Опыт есть опыт, тут ничего не попишешь.

А вот под "ПыСы" это всего лишь предположение. Оно опыт не отменяет.

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

И не будет. Но я-то про другое писал...

Ну я же написал что другое было всего лишь предположением

чо за бизнес-процессы такие, чо за облако, о чом ваще речь?

ННП

Если кому интересно за новые облачные технологии для бизнеса

В ответ на: Если кому интересно за новые облачные технологии для бизнеса

Выступил. Моя презентаха традиционно в тройке по популярности.
Вот тезисы доклада