угу

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

в конце концов греф придёт и скажет

'что ж вы там делаете-то, а'

https://www.vedomosti.ru/technology/news/2016/11/17/665364-sberbank-linkedin

Разрулят, думаю

А зачем? С точки зрения финансов доход из России мизерный. Платных аккаунтов нет почти ни у кого

https://www.vedomosti.ru/technology/news/2016/11/17/665364-sberbank-linkedin

Лол

думаешь им сервера дороже обойдутся чем их выручка с этого сегмента?

думаешь им сервера дороже обойдутся чем их выручка с этого сегмента?

Есть такое подозрение

А зачем? С точки зрения финансов доход из России мизерный. Платных аккаунтов нет почти ни у кого

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

Видимо, важный рынок все равно

Мне лично кровь кипятит любой движ в сторону самоизоляции. Проблема в этом для меня, а не в доступе.

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

Если в маленькой стране мало юзеров, но есть достаточно платных аккаунтов. Ну ты пони

Ну да, но всё ж

Мне лично кровь кипятит любой движ в сторону самоизоляции. Проблема в этом для меня, а не в доступе.

Ну, это уже не борется впном

Тут другие методы)

ладно, джентльмены, я вас тут хотел насчёт другого спросить, на самом деле

насчёт оценки сроков, но не задачу (это привычно более-менее), а на проект

есть какой-то материал/слайды, которые бы хорошо отражали ваш подход к этому?

пока что самое адекватное, что я видел - http://forasoft.github.io/software-estimation/

на русском, правда, но тем не менее

ты теперь ИП?)

ээ, погоди, не уводи с темы ) Сам-то как обычно делаешь? Ты же тимлид как раз :)

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

Я плохой респондент

почему же?

Последние 3 года это был стартап их двух стратапов, где все все время меняется

Мы не оценивали проект наперед

ты имеешь в виду спринты в духе 'так, ребята, концепция изменилась, теперь пилим вот это вместо того'? :)

ага

у нас был бодрый CEO, которые в случае чего сразу мне звонил на телефон практически независимо от времени

:D

"выкидывай весь код, я тут все новое придумал!" в три ночи?

я утрирую конечно)

В общем некоторые вещи можно было сделать лучше. Очень буду стараться изменить это в новой компании

>>В общем некоторые вещи можно было сделать лучше почему-то этим выводом заканчивается вообще всё и всегда

???

насчёт оценки сроков, но не задачу (это привычно более-менее), а на проект

это может тянуть на отдельный проект. бизнес-аналитика и всё такое.

хорошо, если речь о чём-то меньшем? Скажем, двухмесячный кусок.

Более простой случай, чем требующий отдельного проекта по аналитике

как бы ты это сделал? Интуитивно?

хорошо, если речь о чём-то меньшем? Скажем, двухмесячный кусок.

кто тебе сказал, что он двухмесячный? и на сколько людей двухмесячный?

короче, написание ТЗ и его оценка - это отдельные бабки.

Допустим. Это я понял. А примерные методы оценки? Просто собирать требования, прорабатывать до уровня юзер-стори и оценивать?

у МакКонела есть "Software Estimation Costs". Там 300 страниц, правда

ты читал? Хорошая?

я начинал, но не закончил как следует. Но там точно есть ответы на твои вопросы: какие этапы на каком уровне проработки нужно проделать до оценки

спасибо, посмотрю

и когда оценишь не забудь умножить на 2.

мало

на пи надо умножать

ок

в военное время значение пи равно четырем

Умножаем на пи, а потом прибавляем две недели

известная формула)

Ибо за две недели можно сделать что угодно, да :)

у МакКонела есть "Software Estimation Costs". Там 300 страниц, правда

что-то не найти такую книгу..

да, у нас тут искать её и правда тяжко. Но в где-то природе она есть =)

а. нашел http://www.stevemcconnell.com/est.htm

уупс, простите за название

голосовалка про setup.py vs requirements.txt https://plus.google.com/u/0/+SergeMatveenko/posts/jZHgBjNZKek

какой бардак:)

какой бардак:)

zzz там дело говорит

zzz там дело говорит

твоя позиция понятна:) его тоже. ну и как бы, это ко второму пункту голосовалки

если ты закрепил все версии, то ок

но меня парит пихать в проект нечто, куда неопытный юноша может хаков напихать

меня более чем устраивает список зависимостей лежащий статичным файликом

asdf + ql wtf.

ERROR: S client not available

но меня парит пихать в проект нечто, куда неопытный юноша может хаков напихать

а с pypi ты либы качаешь? там же ужасный setup.py написанный неизвестно кем

а неопытного юношу в твоей команде ты должен ревьюить. он же и в requirements насрать может такими темпами

а с pypi ты либы качаешь? там же ужасный setup.py написанный неизвестно кем

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

а неопытного юношу в твоей команде ты должен ревьюить. он же и в requirements насрать может такими темпами

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

а, у тебя просто твой прод ходит в большой pypi напрямую?

а, у тебя просто твой прод ходит в большой pypi напрямую?

ну я условно.

имеется в виду, что закрепляются версии всего, а не только прямых зависимостей

ну свое внутренее хранилище всех пакетов эту проблему решает. туда новое говно внезапно не приедет

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

переписывать setup.py автоматически?

ну свое внутренее хранилище всех пакетов эту проблему решает. туда новое говно внезапно не приедет

это дорого, особенно, если это не on-demand зеркало

по сути ты закрепляешь версию, помещением ее в свое хранилище

это дорого, особенно, если это не on-demand зеркало

тогда же нужна инфра для обновления таки этого хранилища

это дорого, особенно, если это не on-demand зеркало

пффф, копеечная виртуалка с нжинксом и папкой с колесами

пффф, копеечная виртуалка с нжинксом и папкой с колесами

кто и по какому закону туда будет новые версии пихать?

мне с моими файликами для этого нужно просто перегенерить эти файлики

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

всё можно сделать, надо понимать зачем. пока хватает гибкости requirements.txt в репе, я не буду дрыгаться, это время мне никто не оплатит

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

я сам как? руками? мне заняться нечем?

и это у тебя еще просто машин мало, можешь позволить им всем ломануться в большой pypi при деплое

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

после "как угодно еще" разговор можно заканчивать

и это у тебя еще просто машин мало, можешь позволить им всем ломануться в большой pypi при деплое

мне хватает прокси на него

достаточно получить туда пакет один раз.

а версию я закрепил

всё можно сделать, надо понимать зачем. пока хватает гибкости requirements.txt в репе, я не буду дрыгаться, это время мне никто не оплатит

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

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

еще раз, пока у тебя одна репа, неважно сколько у тебя файлов в проекте

тут вопрос хватает или нет.

мы согласились, что пакеты устанавливаемые по зависимостям должны иметь setup.py

также мы согласислись, что надо закреплять версии при конечной интеграции

еще раз, пока у тебя одна репа, неважно сколько у тебя файлов в проекте

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

я утверждаю, что автоматически закреплять версии всего в setup.py неудобно, для этого лучше подходит requirements.txt

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