AN
да. в общем, зашел в настройки автозакачки, убрал автоскачку файлов из пабликгрупп
Size: a a a
2021 March 16
v
Это не GIT но похожий продукт и дока на русском ))
а вот и гит https://tortoisegit.org/
ET
Это не GIT но похожий продукт и дока на русском ))
На самом деле, это не Git и не SVN (что является здесь core), а именно настройка для работы. С таким же успехом можно почитать gitbook. По svn тоже похожие вещи есть.
2021 March 17
EG
Расскажу про трекинг часов с другой стороны баррикад — с точки зрения бизнеса.
Никакого софта у нас нет, экран никто не снимает, кнопок play/pause тоже нет.
В конце рабочего дня каждый сотрудник должен зайти в гуглотабличку и отметить там время в формате «3 часа работал над проектом Х, 4 часа над проектом Y», в некоторых случаях уточнив до конкретной задачи.
Можно ли отработать два часа, а написать восемь? Можно, но мы исходим из того, что если человек решил обмануть компанию, то он это сделает в обход любого софта и любых проверок, поэтому «джентльменам верят на слово».
Можно ли репортить время, не относящееся непосредственно к написанию документов? Можно и нужно: митинги, настройка софта, консультации с коллегами, собственно репорт часов — всё относится к рабочему времени, всё нужно репортить.
Зачем нам вообще трекинг времени? Потому что мы (конкретно мы, не для всех компаний это релевантно) в конечном итоге перепродаем часы сотрудников заказчику. Нам надо точно знать, сколько часов было затрачено на проект, чтобы выставить эту сумму заказчику.
Кроме того, такие репорты — очень важный для бизнеса инструмент статистики и финпланирования. За прошлый месяц 10% рабочего времени ушло на митинги? Это ненормально, давайте что-то с этим делать. R&D и обучение занимают всего 0.0001% от общих часов компании? Давайте это менять.
Никакого софта у нас нет, экран никто не снимает, кнопок play/pause тоже нет.
В конце рабочего дня каждый сотрудник должен зайти в гуглотабличку и отметить там время в формате «3 часа работал над проектом Х, 4 часа над проектом Y», в некоторых случаях уточнив до конкретной задачи.
Можно ли отработать два часа, а написать восемь? Можно, но мы исходим из того, что если человек решил обмануть компанию, то он это сделает в обход любого софта и любых проверок, поэтому «джентльменам верят на слово».
Можно ли репортить время, не относящееся непосредственно к написанию документов? Можно и нужно: митинги, настройка софта, консультации с коллегами, собственно репорт часов — всё относится к рабочему времени, всё нужно репортить.
Зачем нам вообще трекинг времени? Потому что мы (конкретно мы, не для всех компаний это релевантно) в конечном итоге перепродаем часы сотрудников заказчику. Нам надо точно знать, сколько часов было затрачено на проект, чтобы выставить эту сумму заказчику.
Кроме того, такие репорты — очень важный для бизнеса инструмент статистики и финпланирования. За прошлый месяц 10% рабочего времени ушло на митинги? Это ненормально, давайте что-то с этим делать. R&D и обучение занимают всего 0.0001% от общих часов компании? Давайте это менять.
Спасибо огромное!
К
Добрый день! #wanted_tw Технический писатель / Technical writer
Город: Екатеринбург/Челябинск/Санкт-Петербург
Формат: офис, возможна удаленная работа.
Наша компания – NAUMEN, ведущий российский разработчик IT-решений. Мы создаем технологии, которые избавляют от рутины, и помогаем клиентам добиться успеха в мире цифровой экономики.
Сейчас мы в поиске незаменимого человека в команде – Технического писателя в команду разработки Naumen SMP.
Naumen Service Management Platform (SMP) – это платформа, с помощью которой можно быстро настроить и автоматизировать процессы сервисного бизнеса под нужды конкретных компаний.
У нас технический писатель работает в современной системе разработки документации на основе единого источника MadCap Flare. Создаваемый контент используется для публикации на сайте и в виде печатных форм. Разрабатывать документацию - это не только писать тексты, но и возможность применить свои навыки веб-дизайна и стилевого оформления.
Чем нужно будет заниматься?
🔸разработкой и поддержкой пользовательской документации на платформу автоматизации Naumen Service Management Platform и ее интерфейсов (web приложение, мобильное приложение, web портал) в системе MadCap Flare;
🔸 участием в разработке проектной документации (ТЗ, описание системы, руководство пользователя);
🔸 форматированием выпускаемых документов внутри направления по предоставляемым шаблонам;
🔸 взаимодействием с аналитиками и разработчиками в рамках разработки документации.
Важно, чтобы у вас были:
💡 умение работать с большим объемом информации, умение ее структурировать и описывать;
💡 опыт работы в команде на проектах в области разработки/внедрения программного обеспечения;
💡 опыт написания пользовательской документации (инструкции, справки);
💡 ответственность, пунктуальность;
💡 грамотность;
Это всё про вас? Тогда отправляйте резюме на job03@naumen.ru или пишите в Телеграмме @efbobkova😊
Подробнее:
https://www.naumen.ru/career/vacancies/ekb/tekhnicheskiy-pisatel-naumen-smp/
До встречи в NAUMEN!
Город: Екатеринбург/Челябинск/Санкт-Петербург
Формат: офис, возможна удаленная работа.
Наша компания – NAUMEN, ведущий российский разработчик IT-решений. Мы создаем технологии, которые избавляют от рутины, и помогаем клиентам добиться успеха в мире цифровой экономики.
Сейчас мы в поиске незаменимого человека в команде – Технического писателя в команду разработки Naumen SMP.
Naumen Service Management Platform (SMP) – это платформа, с помощью которой можно быстро настроить и автоматизировать процессы сервисного бизнеса под нужды конкретных компаний.
У нас технический писатель работает в современной системе разработки документации на основе единого источника MadCap Flare. Создаваемый контент используется для публикации на сайте и в виде печатных форм. Разрабатывать документацию - это не только писать тексты, но и возможность применить свои навыки веб-дизайна и стилевого оформления.
Чем нужно будет заниматься?
🔸разработкой и поддержкой пользовательской документации на платформу автоматизации Naumen Service Management Platform и ее интерфейсов (web приложение, мобильное приложение, web портал) в системе MadCap Flare;
🔸 участием в разработке проектной документации (ТЗ, описание системы, руководство пользователя);
🔸 форматированием выпускаемых документов внутри направления по предоставляемым шаблонам;
🔸 взаимодействием с аналитиками и разработчиками в рамках разработки документации.
Важно, чтобы у вас были:
💡 умение работать с большим объемом информации, умение ее структурировать и описывать;
💡 опыт работы в команде на проектах в области разработки/внедрения программного обеспечения;
💡 опыт написания пользовательской документации (инструкции, справки);
💡 ответственность, пунктуальность;
💡 грамотность;
Это всё про вас? Тогда отправляйте резюме на job03@naumen.ru или пишите в Телеграмме @efbobkova😊
Подробнее:
https://www.naumen.ru/career/vacancies/ekb/tekhnicheskiy-pisatel-naumen-smp/
До встречи в NAUMEN!
SR
Приветствую собравшихся и прошу консультации: мне очень нужно понять стратегический смысл использования Git не для разработки ПО, а для работы с информацией. Мне удалось найти только много намеков на это но ничего конкретного. А мне очень нужно понять - можно ли вообще использовать Git например в НИОКР или только для ПО?
Добрый день. Попробуйте ответить на вопросы:
1) Будете ли в работах использовать бинарные данные? Если да --- Git не для вас.
2) Готовы ли всю работу сразу вести в BitBucket + Git? Сразу, значит сохранять результаты труда непосредственно в Git.
В Git лучше работать минимальными изменениями. Изменил немного текста --- сделал push в BitBucket. Тогда и ревью делать удобно. В общем, хорош Git, когда мало текста за одно изменение получается. Некоторые поспорят, но хранить XML при больших изменениях --- не всегда удобно. В случае конфликта слияния, искать проблему непросто.
Если предполагается, что вы работаете, сохраняя данные не в Git, и между синхронизациями вашей работы в Bitbucket будут перерывы, Git не самый лучший вариант. Например, TFS или Perforce удобнее. Но они дорогие, поэтому даже те, кто пользовался, отказываются от них.
1) Будете ли в работах использовать бинарные данные? Если да --- Git не для вас.
2) Готовы ли всю работу сразу вести в BitBucket + Git? Сразу, значит сохранять результаты труда непосредственно в Git.
В Git лучше работать минимальными изменениями. Изменил немного текста --- сделал push в BitBucket. Тогда и ревью делать удобно. В общем, хорош Git, когда мало текста за одно изменение получается. Некоторые поспорят, но хранить XML при больших изменениях --- не всегда удобно. В случае конфликта слияния, искать проблему непросто.
Если предполагается, что вы работаете, сохраняя данные не в Git, и между синхронизациями вашей работы в Bitbucket будут перерывы, Git не самый лучший вариант. Например, TFS или Perforce удобнее. Но они дорогие, поэтому даже те, кто пользовался, отказываются от них.
A
Добрый день. Попробуйте ответить на вопросы:
1) Будете ли в работах использовать бинарные данные? Если да --- Git не для вас.
2) Готовы ли всю работу сразу вести в BitBucket + Git? Сразу, значит сохранять результаты труда непосредственно в Git.
В Git лучше работать минимальными изменениями. Изменил немного текста --- сделал push в BitBucket. Тогда и ревью делать удобно. В общем, хорош Git, когда мало текста за одно изменение получается. Некоторые поспорят, но хранить XML при больших изменениях --- не всегда удобно. В случае конфликта слияния, искать проблему непросто.
Если предполагается, что вы работаете, сохраняя данные не в Git, и между синхронизациями вашей работы в Bitbucket будут перерывы, Git не самый лучший вариант. Например, TFS или Perforce удобнее. Но они дорогие, поэтому даже те, кто пользовался, отказываются от них.
1) Будете ли в работах использовать бинарные данные? Если да --- Git не для вас.
2) Готовы ли всю работу сразу вести в BitBucket + Git? Сразу, значит сохранять результаты труда непосредственно в Git.
В Git лучше работать минимальными изменениями. Изменил немного текста --- сделал push в BitBucket. Тогда и ревью делать удобно. В общем, хорош Git, когда мало текста за одно изменение получается. Некоторые поспорят, но хранить XML при больших изменениях --- не всегда удобно. В случае конфликта слияния, искать проблему непросто.
Если предполагается, что вы работаете, сохраняя данные не в Git, и между синхронизациями вашей работы в Bitbucket будут перерывы, Git не самый лучший вариант. Например, TFS или Perforce удобнее. Но они дорогие, поэтому даже те, кто пользовался, отказываются от них.
Спасибо, а если ZIM вместо BitBucket?
SR
Спасибо, а если ZIM вместо BitBucket?
Не работал. Мне казалось, это редактор, а не средство управления версиями. Нет?
OM
Приветствую собравшихся и прошу консультации: мне очень нужно понять стратегический смысл использования Git не для разработки ПО, а для работы с информацией. Мне удалось найти только много намеков на это но ничего конкретного. А мне очень нужно понять - можно ли вообще использовать Git например в НИОКР или только для ПО?
а вы можете вообще поступить изначально по другому?
спросить не про то - можно ли как использовать инструмент ....
а объяснить в чем у вас задача именно и чем не устраивает скажем "разложить все по разным папочкам в проводнике...." ?
может вам тогда изначально чтото более правильное посоветуют...
спросить не про то - можно ли как использовать инструмент ....
а объяснить в чем у вас задача именно и чем не устраивает скажем "разложить все по разным папочкам в проводнике...." ?
может вам тогда изначально чтото более правильное посоветуют...
A
Не работал. Мне казалось, это редактор, а не средство управления версиями. Нет?
Верно, ZIM - это аутлинер, редактор структуры текста, а разве Bucket - не аутлинер?
A
а вы можете вообще поступить изначально по другому?
спросить не про то - можно ли как использовать инструмент ....
а объяснить в чем у вас задача именно и чем не устраивает скажем "разложить все по разным папочкам в проводнике...." ?
может вам тогда изначально чтото более правильное посоветуют...
спросить не про то - можно ли как использовать инструмент ....
а объяснить в чем у вас задача именно и чем не устраивает скажем "разложить все по разным папочкам в проводнике...." ?
может вам тогда изначально чтото более правильное посоветуют...
меня интересует репозитарий для например такой задачи: есть один (1) общий документ, для которого требуется провести оценку разных экспертов (эксперт 1, эксперт 2, ..., эксперт N)... задача состоит в том как сохранить и потом отследить оценку каждого эксперта таким образом, чтобы в итоге получить документ экспертной оценки, состоящий из фрагментов исходного документа (Документ 1), с которыми работали эксперты, так, чтобы для каждого эксперта сохранилась его история оценки и при том оценки бы не перемешивались
A
нечто подобное, как я выяснил недавно (на этой неделе) делает Obsidian, но в форме графа
A
JU
не сказать что выглядит интуитивно понятным
JU
меня интересует репозитарий для например такой задачи: есть один (1) общий документ, для которого требуется провести оценку разных экспертов (эксперт 1, эксперт 2, ..., эксперт N)... задача состоит в том как сохранить и потом отследить оценку каждого эксперта таким образом, чтобы в итоге получить документ экспертной оценки, состоящий из фрагментов исходного документа (Документ 1), с которыми работали эксперты, так, чтобы для каждого эксперта сохранилась его история оценки и при том оценки бы не перемешивались
есть ощущение, что такое можно в редакторе типа Word получить с сохранением правок и комментариев
OM
есть ощущение, что такое можно в редакторе типа Word получить с сохранением правок и комментариев
упрощённо да
но как я понял там нужна автоматизация которой у ворда не вроде нет
но как я понял там нужна автоматизация которой у ворда не вроде нет
OM
упрощённо да
но как я понял там нужна автоматизация которой у ворда не вроде нет
но как я понял там нужна автоматизация которой у ворда не вроде нет
а разбирать в ручную в ворде комментарии... тем более от нескольких авторов... 🙈😖😖😖😖
MC
Подскажите, как назвать колонку с именем создателя объекта.
"Автор" и "Создатель" как-то режут ухо или норм?
PS: остальные колонки в именительном падеже "Дата создания", "Имя" и т.д.
"Автор" и "Создатель" как-то режут ухо или норм?
PS: остальные колонки в именительном падеже "Дата создания", "Имя" и т.д.
AB
Подскажите, как назвать колонку с именем создателя объекта.
"Автор" и "Создатель" как-то режут ухо или норм?
PS: остальные колонки в именительном падеже "Дата создания", "Имя" и т.д.
"Автор" и "Создатель" как-то режут ухо или норм?
PS: остальные колонки в именительном падеже "Дата создания", "Имя" и т.д.
как вариант, "Создан" (род, соответственно, в зависимости от рода самого объекта - Создано, Создана...)
OM
как вариант, "Создан" (род, соответственно, в зависимости от рода самого объекта - Создано, Создана...)
👍🏻 Создан, Создано, Создана - звучит похоже как надо.
как вариант "объект создан" ...
а СОЗДАТЕЛЬ ... 🤔 это про Бога. как говорится не упоминай всуе 🙈😃
как вариант "объект создан" ...
а СОЗДАТЕЛЬ ... 🤔 это про Бога. как говорится не упоминай всуе 🙈😃