Перед тем как ответить, сразу оговоримся, в этой статье мы лишь описали наш ход мыслей при поиске решения в условиях ограниченного времени. Нам хотелось привлечь внимание к данной проблеме и отсутствию легкодоступных однозначных и простых решений. Ресурсов, где описана эта проблема и варианты ее решения по пальцам перечесть. И статей как-то тоже не видно…
1. Да, действительно robot на CI видимо не вариант. До реализации в CI этого решения у нас не дошло, по озвученным в статье причинам.
2. Найти нативное решение все же не так просто. А уж написать самому тем более. Согласны, оно выглядит попроще и читабельнее. Однако если память нам не изменяет, запустить его с ходу у нас не вышло. Поэтому выбрали другое решение.
3. Про данную возможность было известно, но в условиях ограниченного времени лезть в JQuery и изменять что-то в найденном нами решении не хотелось.
Если применить предложенное выше нативное решение, то, пожалуй, благоразумно будет использовать и передачу WebElement.
4. В том то и дело, что проблема, как ни странно, не особо частая. И давать частные случаи при подготовке специалиста возможно только тогда, когда всеми основными знаниями он уже владеет в совершенстве. Увы, такое, на наш взгляд, может себе позволить не каждый.
Спасибо за комментарий. Хотя идеальным решением было бы исправление WebDriver.
Massive view controller упоминался в качестве примера того, что бывает если написание кода на проекте вообще ничем не ограничивать.
Цель примера с UITableView иная — показать императивность UIKit'а, он упрощен для наглядности. Сырые данные или dataSource, в любом случае, придется заводить свойство, доступ к которому получают все единицы класса в пределах исходника.
Все зависит от степени вовлеченности разработчиков в проект и в Rx в частности. Если большая текучка, то стоит подумать о времени, которое новые люди потратят на преодоление порога вхождения, который у библиотеки достаточно высокий, особенно при работе с UI.
А если с кадрами проблем нет, то полный вперед)
По ситуации: Ola Hallengren отличное и очень гибкое решение, его можно рекомендовать почти всегда, хотя зачастую хватает стандартных тасок rebuild/reorganize для maintenance plan.
Старые аудио удаляются в соответствии в data retention policy.
Сложность расшифровки связана со спецификой и сложностью распознавания медицинской терминологии и для клиники экономически выгоднее отдать транскрибирование на аутсорс, чем делать это своими силами. Это позволяет экономить приличные суммы ежегодно.
В момент выявления ошибок не было мыслей куда-то копировать файлы, т.к. ещё не было догадок про аппаратные проблемы и мы даже предположить не могли, что могут отсутствовать бэкапы на лайв системе.
Открытого доступа к данным нет, аудио файлы на диске зашифрованы. На уровне БД настройки шифрования в разных клиниках различаются, как писали в статье, обеспечение сохранности данных — это зона ответственности клиники.
А по другим клиентам настроили мониторинг бэкапов?
— Ответили выше.
Какие именно рекомендации по обслуживанию БД были выданы?
— Перевести модель восстановления БД в режим full, мониторить состояние бэкапов, выполнять бэкапы с проверкой CHECKSUM и проверять бэкапы после создания RESTORE VERIFYONLY. Также, рекомендовали регулярно проводить восстановление из бэкапов на специальном стенде.
Удалось ли выяснить, почему падала виртуалка?
— Нет, наверняка выяснить не удалось, т.к. доступа к хостовой машине и логам не было, но сложилось впечатление, что в поврежденных секторах диска были не только файлы бд, но и какие-то системные, что и приводило к крашу.
Что бы за гипервизор? Что использовалось в качестве хранилища?
— Это выяснить не удалось, т.к. между IT службой клиники и нашей командой был заказчик в качестве посредника, и не вся информация до нас доходила.
Всё верно, на это были требования. Сейчас в БД лежат только документы, аудио хранятся в файловой системе. Но тут скорее проблема не в этом, а промах в администрировании: если бы всё было настроено правильно, не важно какой был бы размер БД и что в ней хранилось.
Приятно видеть, что в век agile помнят про такую замечательную книгу. Вы правы про усиление в последние моменты. В статье идёт речь о том, что руководство таких проектов во время задумывается о расширении, то есть, когда дедлайн уже виден на горизонте и есть достаточно времени для корректировки, не смотря на чувство команды, что все пропало.
В больших проектах работают сильные и компетентные специалисты. И в этих проектах больше уже зависит от истории этого проекта, ограничений, договоренностей и обязательств ПМ и многого другого. Поэтому первая задача в подобных ситуациях обнаружить первопричины текущей ситуации на проекте.
Да, самое интересное, что необходимые действия могут и должны находится за рамками мышления проектной команды)
Например, есть проект состоящий из 8 специалистов. Каждый специалист имеет отличный практический опыт. Процессы налажены согласно последним трендам. Тимлид этой команды матерый технический разработчик с широким кругозором. Однако, объем поставляемых фич хотелось бы улучшить и опытный ПМ полагает, что это осуществимо. Прилагаемые им корректирующие действия не приносят ожидаемых результатов.
В чем на ваш взгляд может быть причина и как ее устранить?
Наша практика показала, что эффективным с точки зрения денег является первоначальное подключение небольшой команды. Таким образом, она погружается в контекст проекта, разрешая различные грабли, встретившиеся на своем пути и уже выходит на более крупные задачи. Затем более безболезненно происходят подключения оставшихся специалистов. Очевидно, что обратной стороной этого подхода будет более длительное по срокам расширение. В случае, если приоритетным являются именно выполнение взятых обязательств, нежели бюджет, второй вариант будет более правильным.
Стоит учитывать, что на практике после дробления задач на мелкие и передачу их выполнения различным специалистам увеличатся накладные расходы на взаимодействие между собой разработчиков и другие активности. Конечно если мы не говорим про крупные фичи, например, от 1-3 человеко\месяцев, которые хорошо параллелятся между собой.
Согласно нашему опыту задачи лучше всего передавать в разработку в перемешку, если брать этот критерий. Это хорошо сказывается на балансе. Не всегда разработчик получает удовлетворение от совсем небольших простых задач, но и если постоянно решать только сложные (зубодробительные) задачи, то есть вероятность, что специалист перегорит.
Мы написали этот материал, потому что это была интересна задача (выбор блокчейна). После решения захотелось поделиться с сообществом, чтобы обратную связь получить.
Ну и идея предложить свой «пробный мини-гайд» по выбору блокчейнов тоже присутствовала, конечно.
Эта статья больше подходит тем, кто ищет блокчейн решение для своего проекта самостоятельно.
Описательная сторона проекта с примерами и деталями реализации обязательно появится, когда мы закончим проект.
Мы расскажем о проекте, когда закончим его разработку.
Конкретно в нашем случае важна иммутабельность введённых туда данных. Иммутабельность данных в децентрализованной базе данных — это полезная операция.
Полный список полезных функций валюты Emercoin вы можете прочитать на сайте.
Насколько эти функции полезны или нет, тут каждый решает сам :)
На данный момент проект находится в активной разработке.
Как только мы сделаем релиз, с удовольствием, расскажем о проекте и его бизнес задачах на Хабре и сделаем кроссылки между статьями.
Причин по которым было разработано собственное приложение несколько:
1) Цель любой компании, в первую очередь, привлекать клиентов именно к своей продукции. Одним из наиболее удобных способов является разработка собственных сервисов и услуг, позволяющих визуализировать возможности конкретной техники.
Конечно можно загрузить бесплатно базы и в Dialux, но там имеется большое множество светотехники различных производителей (порядка 400), а чтобы получить преференции в установке своих баз, производитель должен выплачивать определенную сумму ежегодно.
2) Dialux профессиональная программа, которая может быть достаточно сложна для освоения, и зачастую она излишняя для расчета определенного круга задач.
В этом случае удобнее использовать приложение, специально разработанное для этих целей.
3) У Dialux в данный момент отсутствует мобильная версия и веб-сервисы, поэтому проще и быстрее загрузить приложение Light-in-Night, и сделать расчет освещения на планшете.
В принципе вы правы и для получения физически достоверного освещения именно так и нужжно поступать. Но в данном случае задача получается более упрощенной: Поскольку по госту есть требования минимальной освещенности, то достаточно подсчитать именно интенсивность прямого света, без учета переотраженния, что гарантированно обеспечит освещенность не ниже нормы.
Естетсвенно, можно попытаться сэкономить на освещении и попробовать рассчитать все с учетом переотражений, но это для этого нужно учитывать множество параметров и характеристик каждого конкретного помещения, что конечно экономически не целесообразно и не возможно без дополнительных измерений
1. Да, действительно robot на CI видимо не вариант. До реализации в CI этого решения у нас не дошло, по озвученным в статье причинам.
2. Найти нативное решение все же не так просто. А уж написать самому тем более. Согласны, оно выглядит попроще и читабельнее. Однако если память нам не изменяет, запустить его с ходу у нас не вышло. Поэтому выбрали другое решение.
3. Про данную возможность было известно, но в условиях ограниченного времени лезть в JQuery и изменять что-то в найденном нами решении не хотелось.
Если применить предложенное выше нативное решение, то, пожалуй, благоразумно будет использовать и передачу WebElement.
4. В том то и дело, что проблема, как ни странно, не особо частая. И давать частные случаи при подготовке специалиста возможно только тогда, когда всеми основными знаниями он уже владеет в совершенстве. Увы, такое, на наш взгляд, может себе позволить не каждый.
Спасибо за комментарий. Хотя идеальным решением было бы исправление WebDriver.
Цель примера с UITableView иная — показать императивность UIKit'а, он упрощен для наглядности. Сырые данные или dataSource, в любом случае, придется заводить свойство, доступ к которому получают все единицы класса в пределах исходника.
А если с кадрами проблем нет, то полный вперед)
Сложность расшифровки связана со спецификой и сложностью распознавания медицинской терминологии и для клиники экономически выгоднее отдать транскрибирование на аутсорс, чем делать это своими силами. Это позволяет экономить приличные суммы ежегодно.
— Ответили выше.
Какие именно рекомендации по обслуживанию БД были выданы?
— Перевести модель восстановления БД в режим full, мониторить состояние бэкапов, выполнять бэкапы с проверкой CHECKSUM и проверять бэкапы после создания RESTORE VERIFYONLY. Также, рекомендовали регулярно проводить восстановление из бэкапов на специальном стенде.
Удалось ли выяснить, почему падала виртуалка?
— Нет, наверняка выяснить не удалось, т.к. доступа к хостовой машине и логам не было, но сложилось впечатление, что в поврежденных секторах диска были не только файлы бд, но и какие-то системные, что и приводило к крашу.
Что бы за гипервизор? Что использовалось в качестве хранилища?
— Это выяснить не удалось, т.к. между IT службой клиники и нашей командой был заказчик в качестве посредника, и не вся информация до нас доходила.
Да, самое интересное, что необходимые действия могут и должны находится за рамками мышления проектной команды)
Например, есть проект состоящий из 8 специалистов. Каждый специалист имеет отличный практический опыт. Процессы налажены согласно последним трендам. Тимлид этой команды матерый технический разработчик с широким кругозором. Однако, объем поставляемых фич хотелось бы улучшить и опытный ПМ полагает, что это осуществимо. Прилагаемые им корректирующие действия не приносят ожидаемых результатов.
В чем на ваш взгляд может быть причина и как ее устранить?
Согласно нашему опыту задачи лучше всего передавать в разработку в перемешку, если брать этот критерий. Это хорошо сказывается на балансе. Не всегда разработчик получает удовлетворение от совсем небольших простых задач, но и если постоянно решать только сложные (зубодробительные) задачи, то есть вероятность, что специалист перегорит.
Ну и идея предложить свой «пробный мини-гайд» по выбору блокчейнов тоже присутствовала, конечно.
Эта статья больше подходит тем, кто ищет блокчейн решение для своего проекта самостоятельно.
Описательная сторона проекта с примерами и деталями реализации обязательно появится, когда мы закончим проект.
Конкретно в нашем случае важна иммутабельность введённых туда данных. Иммутабельность данных в децентрализованной базе данных — это полезная операция.
Полный список полезных функций валюты Emercoin вы можете прочитать на сайте.
Насколько эти функции полезны или нет, тут каждый решает сам :)
Как только мы сделаем релиз, с удовольствием, расскажем о проекте и его бизнес задачах на Хабре и сделаем кроссылки между статьями.
1) Цель любой компании, в первую очередь, привлекать клиентов именно к своей продукции. Одним из наиболее удобных способов является разработка собственных сервисов и услуг, позволяющих визуализировать возможности конкретной техники.
Конечно можно загрузить бесплатно базы и в Dialux, но там имеется большое множество светотехники различных производителей (порядка 400), а чтобы получить преференции в установке своих баз, производитель должен выплачивать определенную сумму ежегодно.
2) Dialux профессиональная программа, которая может быть достаточно сложна для освоения, и зачастую она излишняя для расчета определенного круга задач.
В этом случае удобнее использовать приложение, специально разработанное для этих целей.
3) У Dialux в данный момент отсутствует мобильная версия и веб-сервисы, поэтому проще и быстрее загрузить приложение Light-in-Night, и сделать расчет освещения на планшете.
Естетсвенно, можно попытаться сэкономить на освещении и попробовать рассчитать все с учетом переотражений, но это для этого нужно учитывать множество параметров и характеристик каждого конкретного помещения, что конечно экономически не целесообразно и не возможно без дополнительных измерений