А в чем смысл подключать sbt-native-packager и писать Dockerfile? Если можно просто вызвать комаду:
sbt docker:publishLocal
или
sbt docker:publish
Все что оставалось — дописать в build.sbt строку с указаением выставляемого порта:
dockerExposedUdpPorts += 8080
Можно было просто подключить sbt-assembly и на это ограничится, если по каким-то причинам сами хотите писать Dockerfile сами. Да и к тому же и sbt-assembly и sbt-native-packager уже сами вызывают запуск тестов, зачем отдельно это еще делать?
То что ситуация попытка давления — я не исключаю. Я про то, что было бы здорово разъяснить что значат наши законы. Если я веду свой проект и делаю в него коммиты в рабочее время, с рабочего оборудования — это мое или работодателя? А если в не рабочее, но у меня ненормированный график прописан, или «плавающий»?
А как быть в ситуации, например, если вечерами я стал писать, свою встраиваемую базу данных и выкладывать ее в opensource, а в рабочем проекте ее потом стал использовать? Или не БД, а какую-то библиотеку.
В целом грустно наблюдать такую ситуацию, но в вопрос к этому пункту:
Ситуация, когда каждый программист при любом коммите в open source проект, должен задумываться о юридической безопасности своих действий, представляется нам стоп-фактором для развития отрасли.
Почему в Силиконовой Долине, так можно, а в РФ плохо (сужу по фильму Силиконовая Долина)? Может лучше выпустить разъясняющие материалы, которые объясняют, чем с юридической точки зрения могут закончится коммиты в opensource и объясняют простым языком, что можно, а что нельзя и что значат типовые формы в дополнениях к трудовым договорам о передаче прав на интеллектуальную собственность компании-работадателю. И конечно что будет, если ты начал свой собственный проект, да еще ведешь его на оборудовании предоставленном компанией (и влияет ли это).
Почему вместо того, чтобы призвать разработчиков осознавать, что они делают, что они подписывают устраиваясь на работу, Вы призываете компании не пользоваться текущим законодательством? Программисты — они не разумные дети, которые не могут нести отвественность за свои поступки и могут только «кнопочки давить»?
Если сотрудники много коммуницируют в чате, а все сидят в опенспейсе, то будучи рядом, они начнут коммуницировать голосом. Как плюс, повысится эффективность коммуникации (во-первых голос; во-вторых, можно нарисовать что-то на листочке или просто показать свой экран). Но есть и ряд минусов: если это опенспейс, то разговоры могут мешать остальным; разговоры голосом не документируются и кроме уавствующих больше о нем никто может не узнать, в то время как общение в общем чате доступно для всех и выше вероятность, что его заметит еще кто-то кого тема коснется.
Вывод? А никакого вывода, просто взгляд с другой колокольни. :)
Указанноу проблему пытается решить мутационное тестирование. Фреймворки для него, обычно, смотрят какой код покрыт тестами, далее формируют единичные изменения (мутации) и на каждое изменение производят запуск тестов. В результате отображают какие изменение были отловлены (какие мутанты убиты) и какими тестами, а какие мутанты выжили. Но если мутант выжил, то не обязательно проблема в тестах, вполне возможно, что есть избыточные проверки в коде и тесты не могли в принципе упасть. Ну или мутация «задела» какой-нибудь «ассерт».
Мутационное тестирование в проекты! :) И уже делать псевдо покрытие кода становится чуть сложнее. Хотя если человек не хочет писать тесты, то всегда найдет способ как их не писать :)
Да, конечно, это можно сделать. Это можно батник (из него вызвать git commit и если код возврата 0, то отправлять изменения на сервера последующими командами). Еще можно попробовать посмотреть на локальные хуки гита, которые будут срабатывать после комита (не уверен, можно ли из них отправить изменения на сервер).
Кажется, что tortoise git как раз и делал отправку изменений на сервер сразу после комита, но могу ошибаться. Я не очень люблю клиенты для git, так как в них очень легко можно наворотить что-нибудь не то, а потом придется разгребать. С этим сталкивался не раз, поэтому предпочитаю работать с консолью — выше осознаность действий.
Крайне обидно слышать, придя с заявлением на увольнение, что вот еще бы недельку другую и они сами бы все предложили и подняли. Я вот работу работать хочу спокойно и качественно, а не пытаться выбить себе денег побольше. И почему-то просьба о прибавке з/п и заявление на увольнение, работает эффективнее, чем только просьба о прибавке зарплаты.
Работа с Git/Меркуриал подразумевает большее количество шагов — добавить в "индекс", сделать локальный коммит, отправить коммит на сервер.
Если Вы работаете с репозиторием один, то использование практики ветка-на-фичу, мне кажется излишней — потренироваться работать с ветками — да, пожалуй, но на постоянной основе — особого смысла нет. Это дает преимущества когда над проектом активно работает несколько человек. В этом случае удобно использовать ветки, чтобы не вливать сырые изменения в основную (trunk/master).
Я использовал связку, так как в процессе работы мне было удобно делать локальные коммиты и отправлять промежуточные результаты работы в отдельный hg-репозиторий (потом git-репозиторий). Срок выполнения задачи был большим, поэтому я делал коммит каждый день с тем на чем закончил, иногда делал дополнительные ветки, чтобы попробовать какой-нибудь альтернативный вариант решения. После того как задача решена, объединял все коммиты в один и отправлял в SVN.
К сожалению одной командой отправить изменения в SVN и другой git-репозиторий не получится. Не зависимо, что Вы выберете git-svn или hgsvn сценарий будет примерно такой:
Еще можно на bitbucket.org — там есть что использовать — git или mercurial. Я вот даже не знаю, кто мне больше нравится git или mercurial, в некоторых вещах — меркуриал нравится больше, как минимум из-за отслеживания, что файл был скопирован и в него внесены изменения, ну и Tortoise Hg как-то адекватнее себя ведет, чем Tortoise Git.
Но с репозиторием SVN можно работать и через Git. Получается, в целом, не плохо. Я работал с SVN через меркуриал (hgsvn) и git-svn. В целом, git-svn поудобнее, но бывали проблемы с клонированием SVN репозитория — если он большой, то клонируется очень долго, и иногда падает — приходилось подбирать параметры. С hgsvn такого не было, но он и не клонировал репозиторий, это фактически было в одном каталоге два репозитория — SVN и меркуриал, а утилита hgsvn позволяла их синхронизировать. Это было менее удобно, но позволяло не вытягивать при помощи hgsvn всю историю, а пользоваться историем SVN.
А я начал использовать Vim, а точнее gVim из-за удобства использования замены по регулярным выражениям, а именно, что можно было выражение интерпретировать как число и его инкрементировать, относительно часто приходилось делать подобное. А еще язык плагинов довольно простой, и можно быстро наваять что-то полезное для себя. Пробовал spacemacs, но как-то не зашло, хотя он произвел очень приятное впечатление.
а каким словом называеться тимлид в scrum документах ?
Если я правильно понимаю, то в гибких методология нет иерархии, т.е. там нет тимлида. Предполагается, что уровень в команде ± одинаковый и все участники команды разработки равноправны. Владелец-продукта — это не начальник, он отвечает, за набор задач и их приоритет, но вмешиваться в дела команды не имеет права. Ну а SM — это вообще наблюдатель, который хоть и является членом команды, но может только советовать/рекомендовать. А следовать его советам или нет — это уже решать остальным участникам.
Зависит от ировня интерактивности, для начала можно отображать статичную страницу с применеными стилями и, опционально, возможностью перехода по гиперссылке. Как мне кажется, этого уже достаточно, чтобы его можно было начать использовать где-нибудь еще и привлечь внимание разработчиков.
К общим замечаниям, если планируете привлечь других разработчиков, то выложите в репозиторий правила форматироавния для какого-нибудь распространенного автоформатера кода. Судя по всему вы форматируете код в ручную, что не очень хорошо для привлечения других разрабоотчиков — не все форматируют как так же. Так же попробуйте начать использовать тесты, проект новый, принимаемые решения могут оказаться не удачными спустя какое-то время, а с тестами и рефакторинг проще, и частично они помогу прояснить, какое поведение ожидалось.
Отличный труд! Но, мне кажется, лучше стараться делать функции чистыми и отказываться от модификации передаваемых аргументов. Если хочется изменить входной аргумент — пусть функция вернет модифицированную копию. Это не всегда возможно, но к этому стоит стремиться. Такой код проще читать и проще тестировать.
Бизнесу не выгодно бесконечно развивать продукт, если он провальный, а в случае если он успешный и постоянно развивается, то команда разработки имеет постоянный доход. Если команде разработки надоело поддерживать продукт она может закончить работу на любом спринте.
Речь не про изменение ТЗ на ходу. Когда есть конкретное ТЗ, то нет места скраму. Это две разные модели. Если работать по ТЗ (в идеальном мире), то заказчик выдает определенный набор требования, команда оценивает и называет срок и сумму. В указанный срок заказчик приходит и ему отдают готовый протестированный продукт. Т.е. фактически покупается конечный продукт, в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработки.
Он выдвигает набор требований, какое-то подмножество наиболее актуальных реализуется и отдается заказчику на использование, команда начинает работу над следующим набором. В процессе использования у заказчика появляются новые требования, новые запросы и так далее, пока заказчику не надоест улучшать/переделывать продукт.
Изучаю Scala: Часть 2 — Todo лист с возможностью загрузки картинок
А в чем смысл подключать sbt-native-packager и писать Dockerfile? Если можно просто вызвать комаду:
или
Все что оставалось — дописать в build.sbt строку с указаением выставляемого порта:
Можно было просто подключить sbt-assembly и на это ограничится, если по каким-то причинам сами хотите писать Dockerfile сами. Да и к тому же и sbt-assembly и sbt-native-packager уже сами вызывают запуск тестов, зачем отдельно это еще делать?
И зачем запускать тесты, если их нет?
Официальная позиция Программных комитетов Highload++ и других IT-конференций на претензии к Игорю Сысоеву…
Официальная позиция Программных комитетов Highload++ и других IT-конференций на претензии к Игорю Сысоеву…
Официальная позиция Программных комитетов Highload++ и других IT-конференций на претензии к Игорю Сысоеву…
Почему в Силиконовой Долине, так можно, а в РФ плохо (сужу по фильму Силиконовая Долина)? Может лучше выпустить разъясняющие материалы, которые объясняют, чем с юридической точки зрения могут закончится коммиты в opensource и объясняют простым языком, что можно, а что нельзя и что значат типовые формы в дополнениях к трудовым договорам о передаче прав на интеллектуальную собственность компании-работадателю. И конечно что будет, если ты начал свой собственный проект, да еще ведешь его на оборудовании предоставленном компанией (и влияет ли это).
Почему вместо того, чтобы призвать разработчиков осознавать, что они делают, что они подписывают устраиваясь на работу, Вы призываете компании не пользоваться текущим законодательством? Программисты — они не разумные дети, которые не могут нести отвественность за свои поступки и могут только «кнопочки давить»?
Как рассадить всех по науке и не превратить кабинет в рассадник ненависти
Вывод? А никакого вывода, просто взгляд с другой колокольни. :)
Как писать юнит-тесты, если совсем не хочется
Как писать юнит-тесты, если совсем не хочется
Newtoo — разработка полноценного браузерного движка с нуля в 2018?
Кажется, что tortoise git как раз и делал отправку изменений на сервер сразу после комита, но могу ошибаться. Я не очень люблю клиенты для git, так как в них очень легко можно наворотить что-нибудь не то, а потом придется разгребать. С этим сталкивался не раз, поэтому предпочитаю работать с консолью — выше осознаность действий.
Так что же не так с поиском работы/работников в ИТ?
Newtoo — разработка полноценного браузерного движка с нуля в 2018?
Работа с Git/Меркуриал подразумевает большее количество шагов — добавить в "индекс", сделать локальный коммит, отправить коммит на сервер.
Если Вы работаете с репозиторием один, то использование практики ветка-на-фичу, мне кажется излишней — потренироваться работать с ветками — да, пожалуй, но на постоянной основе — особого смысла нет. Это дает преимущества когда над проектом активно работает несколько человек. В этом случае удобно использовать ветки, чтобы не вливать сырые изменения в основную (trunk/master).
Я использовал связку, так как в процессе работы мне было удобно делать локальные коммиты и отправлять промежуточные результаты работы в отдельный hg-репозиторий (потом git-репозиторий). Срок выполнения задачи был большим, поэтому я делал коммит каждый день с тем на чем закончил, иногда делал дополнительные ветки, чтобы попробовать какой-нибудь альтернативный вариант решения. После того как задача решена, объединял все коммиты в один и отправлял в SVN.
К сожалению одной командой отправить изменения в SVN и другой git-репозиторий не получится. Не зависимо, что Вы выберете git-svn или hgsvn сценарий будет примерно такой:
Newtoo — разработка полноценного браузерного движка с нуля в 2018?
Но с репозиторием SVN можно работать и через Git. Получается, в целом, не плохо. Я работал с SVN через меркуриал (hgsvn) и git-svn. В целом, git-svn поудобнее, но бывали проблемы с клонированием SVN репозитория — если он большой, то клонируется очень долго, и иногда падает — приходилось подбирать параметры. С hgsvn такого не было, но он и не клонировал репозиторий, это фактически было в одном каталоге два репозитория — SVN и меркуриал, а утилита hgsvn позволяла их синхронизировать. Это было менее удобно, но позволяло не вытягивать при помощи hgsvn всю историю, а пользоваться историем SVN.
SNMP + Java – личный опыт. Пишем парсер MIB-файлов
Кажется заголовок излишне громкий. В чем "невозможность", в том что нет вот сразу готовой библиотеки, которая все делает?
"Парсер"? Серьезно? Просто обернули в методы стороннюю библиотеку и это уже парсер.
В целом статья полезная, но заголовок уж слишком "кричащий".
Как Vim украл моё сердце
Scrum is dead
Если я правильно понимаю, то в гибких методология нет иерархии, т.е. там нет тимлида. Предполагается, что уровень в команде ± одинаковый и все участники команды разработки равноправны. Владелец-продукта — это не начальник, он отвечает, за набор задач и их приоритет, но вмешиваться в дела команды не имеет права. Ну а SM — это вообще наблюдатель, который хоть и является членом команды, но может только советовать/рекомендовать. А следовать его советам или нет — это уже решать остальным участникам.
Newtoo — разработка полноценного браузерного движка с нуля в 2018?
Зависит от ировня интерактивности, для начала можно отображать статичную страницу с применеными стилями и, опционально, возможностью перехода по гиперссылке. Как мне кажется, этого уже достаточно, чтобы его можно было начать использовать где-нибудь еще и привлечь внимание разработчиков.
К общим замечаниям, если планируете привлечь других разработчиков, то выложите в репозиторий правила форматироавния для какого-нибудь распространенного автоформатера кода. Судя по всему вы форматируете код в ручную, что не очень хорошо для привлечения других разрабоотчиков — не все форматируют как так же. Так же попробуйте начать использовать тесты, проект новый, принимаемые решения могут оказаться не удачными спустя какое-то время, а с тестами и рефакторинг проще, и частично они помогу прояснить, какое поведение ожидалось.
Манифест Чистого Программиста или краткий конспект книги «Чистый Код» Роберта Мартина
А был ли Scrum*?
А был ли Scrum*?
комментарий удален
А был ли Scrum*?
А был ли Scrum*?
Речь не про изменение ТЗ на ходу. Когда есть конкретное ТЗ, то нет места скраму. Это две разные модели. Если работать по ТЗ (в идеальном мире), то заказчик выдает определенный набор требования, команда оценивает и называет срок и сумму. В указанный срок заказчик приходит и ему отдают готовый протестированный продукт. Т.е. фактически покупается конечный продукт, в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработки.
Он выдвигает набор требований, какое-то подмножество наиболее актуальных реализуется и отдается заказчику на использование, команда начинает работу над следующим набором. В процессе использования у заказчика появляются новые требования, новые запросы и так далее, пока заказчику не надоест улучшать/переделывать продукт.
Это если применительно к ИТ.