Во-первых, это далеко не бесплатно, т.е. это работа (и она еще занимает время), и во-вторых, далеко не всегда вы вообще понимаете, на какие операции нужно декомпозировать. И пока всю систему не спроектируете - не узнаете. Ну т.е. я бы сказал, что тут компромисс между точностью прогноза, и моментом, когда вы можете его дать. Чем позже - тем у вас как правило в наличии более точная декомпозиция задач, и более точный прогноз. Но магически получить прогноз раньше на год с той же точностью вы не сможете.
Паттерны (просто по определению) - это про типовые решения типовых задач. Начинающим давать их в курсе обучения вообще противопоказано - они как правило просто не имеют опыта решения типовых задач, для них все задачи новые. Поэтому я вовсе не про то, что автору в курсе нужно было давать memento, и это правильно. Нет.
Я скорее про то, что когда программист без опыта делает выводы, что ему вот это и вот это не нужно - это слегка самоуверенно. Типовой начинающий программист даже увидев паттерн где-то на SO, и применив его у себя, не всегда поймет, что он применил.
P.S. Вообще говоря, полгода в самом начале это еще не опыт. Это обычно то время, когда человек только и делает, что отрывает более опытных от работы, не принося при этом пользы. Так что из года надо сразу вычесть половину )
Знания программиста — все что нужно для создания ПО
Очевидный ответ (сильно упрощенный) - потому что знания программиста далеко не все, что нужно. Иногда нужны знания из определенной области, иногда нужен маркетинг, иногда дизайн. Это только то что сразу в голову приходит. Если этих вещей нет - успех ПО иногда тоже возможен, но по описанным выше причинам выделиться на фоне других имея только код может быть сложно.
Как часто вы используете в повседневной жизни memento?
Простите, но вы же кондитер? Ну ок, уже не совсем кондитер, но вы программист без опыта. С какой стати вы делаете такие обобщения, не имея для этого никаких оснований?
Все еще не улавливаю, почему проще-то? Ведь по сути, чтобы понять, сумеем ли мы выполнить задачи к такому-то, нам все равно нужно:
получить список задач, определиться с зависимостями между ними, построить критический путь
для каждой задачи прикинуть распределение времени выполнения
получить распределение времени выполнения всех задач на критическом пути
Ответ "Да, мы успеваем" эквивалентен тому, что дата старта + время выполнения задач с критического пути с определенной вероятностью меньше требуемой даты завершения.
Единственное что меняется, если мы фиксируем дату завершения - это наверное объем работ. И его можно сократить, если мы понимаем, что не успеваем. Но чтобы понять - все равно надо проделать вот этот весь анализ. Про который вы сами написали, что он сложный :)
Ну т.е. если совсем просто - информация-то для анализа все равно нужна та же самая, разве нет? Мне кажется, эта простота - чисто психологическая. Нам удобнее иметь дело с задачей в такой постановке.
Прокрутите это в голове и сравните два вопроса: «Когда вы выполните эту задачу?» и «Сможем ли мы решить задачу к такому-то сроку?» На какой вам будет проще ответить?
На мой взгляд, ответ на второй вопрос (от человека, разбирающегося в планировании), никогда не будет "Да" или "Нет", а будет что-то вроде "Да, с вероятностью 0.01". То есть, скорее всего нет, но может быть что и да.
И ничего при этом на практике от смены постановки вопроса не поменяется, потому что знать эту вероятность вы все равно будете очень приблизительно. По крайней мере для задач, которые вы никогда раньше не делали, и не имеете четкого представления об их сложности. То есть, вместо нечеткого ответа на вопрос "когда" вы получите такой же нечеткий ответ на вопрос, с какой вероятностью мы получим результат, разве нет?
Под эти условия наверное да, ручное решение может оказаться самым быстрым. Все-таки, найти и настроить готовое - нужно время.
Хотя как вон там ниже написали - сначала собрать все с доступом к интернету, вам pip все файлики сложит на диск - потом это все заархивировать и перенести в изолированный сегмент, и там установить - тоже выглядит решением.
Не, так новичкам так может быть даже проще. Поставить тот же нексус - ну это может пол дня. Зато потом это будет полноценное решение. Я не возмущаюсь, а скорее удивляюсь, что не попробовали поискать готовое решение, которое несомненно есть.
Ну кстати. решение с докером тоже может быть вариантом. Причем опять же, как вариант проксирующего docker registry, который будет стоять между сегментами, а собирать образы вы будете с доступом в интернет. Самое смешное, что тот же нексус это снова умеет. И да, вариант с репозиторием RPM тоже есть.
Решение этой проблемы известно уже много лет - допустим, широко известный Nexus (который вообще из мира Java) в бесплатной версии умеет работать прокси репозиторием pypi уже лет 10 наверное. При этом вокруг него можно строить решение, которое будет контролировать безопасность устанавливаемых модулей.
Я уверен, что в питон мире есть и другие решения для подъема проксирующего сервера подобного назначения. Просто вы их не там ищете. Неужели вы думаете, что вы первый, кто оказался в изолированном сегменте без интернета? Да все банки так уже лет 20 живут.
Ну я видел на ютюбе ролик, где британские строители применяют вживую exoactive. По нашим ценам я не могу себе представить, чтобы это стоило дешевле еще одного наемного рабочего, но с другой стороны, если рабочего надо нанять на целый день, а помогать он будет от силы 15 минут... то черт его знает. В конце концов, это лишь цена еще одного (пусть и недешевого) инструмента.
Кто знает: быть может, где-то в мире уже трудится неизвестный умелец, который вот-вот явит человечеству прорывной концепт.
Между тем, фирма festool уже продает серийный экзоскелет за цену порядка 500к рублей. При этом возможности его достаточно на первый взгляд примитивные - 5 килограмм прибавки к силе рук в течение 1.5 - 5 часов от одной батареи 18В. Ну т.е. это вполне себе практическая штука, позволяющая условному строителю легче удерживать над головой скажем лист гипсокартона (весящий до 30 килограмм) при монтаже потолочного перекрытия.
Условно есть массив на 100к элеметов типа String. В каждой ячейки массива лежит строка на 100к символов кодировки UTF-8. Сколько памяти потребуется, чтобы разместить такой массив в памяти компьютера?
Вообще-то в JVM в ячейке массива лежит указатель на строку, а не строка, как и для любого массива, содержащего не примитивы. Т.е. для 64-битной JVM это 100к 8-байтовых указателей, т.е. 800к. А строки лежат например в куче. Кроме того, длина строки не является частью сигнатуры типа для массива, поэтому при создании массива никакие 100к под один элемент не выделяются и не предполагаются, потому что эти строки уже где-то размещены к этому моменту (например в куче). И они могут быть разной длины.
Я много раз ходил этим путем. Для человека, который зашел по дороге, там нет ничего интересного. Продукты (кажется Перекресток) в стороне, ну вот разве что пиццы купить в фудкорте. Наличие потока людей между станциями похоже никто никогда не учитывал.
А где я говорил что приклеиваем? Я говорю, что даже чисто технически это сложно реализовать, если ты только банк, и у тебя нет координат с мобильника. И варианты типа покупки этих данных у сотового оператора - тоже не такое простое решение, во-первых, потому что операторов больше одного, а во-вторых, это же не единоразовая акция, это же желательно канал постоянной поставки таких данных иметь.
Причем довольно очевидно, что если сотовый оператор не дурак, он со своей стороны такой аналитикой тоже интересуется, и пытается эти же данные у себя достроить, чтобы продать тем же банкам, но подороже, и обезличенные, чтобы не иметь проблем с регулятором.
Всякие правовые аспекты - это совершенно другая, и наверное не менее сложная история.
Вот кстати, мотивации иногда в этом списке не хватает. Некоторые советы правда очевидны, но некоторые вовсе нет. Один пример - что значит не используйте UNION? Этож почти тоже самое что не используйте where, а то будет медленно :) Более осмысленно было бы порекомендовать что-то на замену.
Ну мы кстати пытались. Вот представь, что у тебя есть под рукой биллинг (по картам твоего банка). И в этом биллинге написано, что человек заплатил какому-то ООО Вася Пупкин (название латиницей, транслитерация) столько-то денег непонятно за что. Биллинг этот присылает тебе Visa, ну или в общем, некая карточная система, и составлен он по ее стандартам. И адрес там тоже написан так, что геокодировать его удается скажем в 80% случаев. Да, еще биллинг это терабайты в день, скажем, и работать с ним не так и просто чисто технически.
Короче говоря, если это POS терминал не принадлежит своему банку, то исследовать платежи даже в такой ситуации далеко не тривиально. Вплоть до того, что мы начали применять всякие эвристики типа того, что если платежи А и Б были произведены в течение 5 минут - значит POS Б (это например банк конкурент) находится где-то близко от POS А (который нашего банка, и мы даже знаем координаты), и мы можем примерно прикинуть, где этот POS стоит, даже не имея правильного адреса, ну или уточнить результат геокодирования. С кучей допущений, что человек скажем шел пешком, и за 5 минут удалился не более чем на ... (а если он на самокате?).
Даже будучи банком, это не так просто, не все удается определить, что может быть интересно. Удобнее всего когда у человека в кармане смартфон, и там стоит твое платежное приложение, и каждый платеж сопровождается координатами, помимо всего остального. Да и то остаются вопросы при платежах скажем за билет в трамвае ;) Ну или нужно сочетать данные банка, и скажем сотового провайдера - а это уже сложная задача, причем не технически.
Во-первых, это далеко не бесплатно, т.е. это работа (и она еще занимает время), и во-вторых, далеко не всегда вы вообще понимаете, на какие операции нужно декомпозировать. И пока всю систему не спроектируете - не узнаете. Ну т.е. я бы сказал, что тут компромисс между точностью прогноза, и моментом, когда вы можете его дать. Чем позже - тем у вас как правило в наличии более точная декомпозиция задач, и более точный прогноз. Но магически получить прогноз раньше на год с той же точностью вы не сможете.
Паттерны (просто по определению) - это про типовые решения типовых задач. Начинающим давать их в курсе обучения вообще противопоказано - они как правило просто не имеют опыта решения типовых задач, для них все задачи новые. Поэтому я вовсе не про то, что автору в курсе нужно было давать memento, и это правильно. Нет.
Я скорее про то, что когда программист без опыта делает выводы, что ему вот это и вот это не нужно - это слегка самоуверенно. Типовой начинающий программист даже увидев паттерн где-то на SO, и применив его у себя, не всегда поймет, что он применил.
P.S. Вообще говоря, полгода в самом начале это еще не опыт. Это обычно то время, когда человек только и делает, что отрывает более опытных от работы, не принося при этом пользы. Так что из года надо сразу вычесть половину )
И что из этого следует, кроме того, что ваш опыт специфический (как и любой другой)?
Очевидный ответ (сильно упрощенный) - потому что знания программиста далеко не все, что нужно. Иногда нужны знания из определенной области, иногда нужен маркетинг, иногда дизайн. Это только то что сразу в голову приходит. Если этих вещей нет - успех ПО иногда тоже возможен, но по описанным выше причинам выделиться на фоне других имея только код может быть сложно.
Простите, но вы же кондитер? Ну ок, уже не совсем кондитер, но вы программист без опыта. С какой стати вы делаете такие обобщения, не имея для этого никаких оснований?
Все еще не улавливаю, почему проще-то? Ведь по сути, чтобы понять, сумеем ли мы выполнить задачи к такому-то, нам все равно нужно:
получить список задач, определиться с зависимостями между ними, построить критический путь
для каждой задачи прикинуть распределение времени выполнения
получить распределение времени выполнения всех задач на критическом пути
Ответ "Да, мы успеваем" эквивалентен тому, что дата старта + время выполнения задач с критического пути с определенной вероятностью меньше требуемой даты завершения.
Единственное что меняется, если мы фиксируем дату завершения - это наверное объем работ. И его можно сократить, если мы понимаем, что не успеваем. Но чтобы понять - все равно надо проделать вот этот весь анализ. Про который вы сами написали, что он сложный :)
Ну т.е. если совсем просто - информация-то для анализа все равно нужна та же самая, разве нет? Мне кажется, эта простота - чисто психологическая. Нам удобнее иметь дело с задачей в такой постановке.
На мой взгляд, ответ на второй вопрос (от человека, разбирающегося в планировании), никогда не будет "Да" или "Нет", а будет что-то вроде "Да, с вероятностью 0.01". То есть, скорее всего нет, но может быть что и да.
И ничего при этом на практике от смены постановки вопроса не поменяется, потому что знать эту вероятность вы все равно будете очень приблизительно. По крайней мере для задач, которые вы никогда раньше не делали, и не имеете четкого представления об их сложности. То есть, вместо нечеткого ответа на вопрос "когда" вы получите такой же нечеткий ответ на вопрос, с какой вероятностью мы получим результат, разве нет?
На 20 лет тоже в нашей отрасли иногда очень самоуверенно прогнозировать.
Не, сорри. Я скорее про то, что точно такой же вариант уже в комментариях предложили :) Ну то есть, он таки напрашивается как один из.
Под эти условия наверное да, ручное решение может оказаться самым быстрым. Все-таки, найти и настроить готовое - нужно время.
Хотя как вон там ниже написали - сначала собрать все с доступом к интернету, вам pip все файлики сложит на диск - потом это все заархивировать и перенести в изолированный сегмент, и там установить - тоже выглядит решением.
Не, так новичкам так может быть даже проще. Поставить тот же нексус - ну это может пол дня. Зато потом это будет полноценное решение. Я не возмущаюсь, а скорее удивляюсь, что не попробовали поискать готовое решение, которое несомненно есть.
Ну кстати. решение с докером тоже может быть вариантом. Причем опять же, как вариант проксирующего docker registry, который будет стоять между сегментами, а собирать образы вы будете с доступом в интернет. Самое смешное, что тот же нексус это снова умеет. И да, вариант с репозиторием RPM тоже есть.
Решение этой проблемы известно уже много лет - допустим, широко известный Nexus (который вообще из мира Java) в бесплатной версии умеет работать прокси репозиторием pypi уже лет 10 наверное. При этом вокруг него можно строить решение, которое будет контролировать безопасность устанавливаемых модулей.
Я уверен, что в питон мире есть и другие решения для подъема проксирующего сервера подобного назначения. Просто вы их не там ищете. Неужели вы думаете, что вы первый, кто оказался в изолированном сегменте без интернета? Да все банки так уже лет 20 живут.
Ну я видел на ютюбе ролик, где британские строители применяют вживую exoactive. По нашим ценам я не могу себе представить, чтобы это стоило дешевле еще одного наемного рабочего, но с другой стороны, если рабочего надо нанять на целый день, а помогать он будет от силы 15 минут... то черт его знает. В конце концов, это лишь цена еще одного (пусть и недешевого) инструмента.
Между тем, фирма festool уже продает серийный экзоскелет за цену порядка 500к рублей. При этом возможности его достаточно на первый взгляд примитивные - 5 килограмм прибавки к силе рук в течение 1.5 - 5 часов от одной батареи 18В. Ну т.е. это вполне себе практическая штука, позволяющая условному строителю легче удерживать над головой скажем лист гипсокартона (весящий до 30 килограмм) при монтаже потолочного перекрытия.
Вообще-то в JVM в ячейке массива лежит указатель на строку, а не строка, как и для любого массива, содержащего не примитивы. Т.е. для 64-битной JVM это 100к 8-байтовых указателей, т.е. 800к. А строки лежат например в куче. Кроме того, длина строки не является частью сигнатуры типа для массива, поэтому при создании массива никакие 100к под один элемент не выделяются и не предполагаются, потому что эти строки уже где-то размещены к этому моменту (например в куче). И они могут быть разной длины.
Я много раз ходил этим путем. Для человека, который зашел по дороге, там нет ничего интересного. Продукты (кажется Перекресток) в стороне, ну вот разве что пиццы купить в фудкорте. Наличие потока людей между станциями похоже никто никогда не учитывал.
А где я говорил что приклеиваем? Я говорю, что даже чисто технически это сложно реализовать, если ты только банк, и у тебя нет координат с мобильника. И варианты типа покупки этих данных у сотового оператора - тоже не такое простое решение, во-первых, потому что операторов больше одного, а во-вторых, это же не единоразовая акция, это же желательно канал постоянной поставки таких данных иметь.
Причем довольно очевидно, что если сотовый оператор не дурак, он со своей стороны такой аналитикой тоже интересуется, и пытается эти же данные у себя достроить, чтобы продать тем же банкам, но подороже, и обезличенные, чтобы не иметь проблем с регулятором.
Всякие правовые аспекты - это совершенно другая, и наверное не менее сложная история.
Вот кстати, мотивации иногда в этом списке не хватает. Некоторые советы правда очевидны, но некоторые вовсе нет. Один пример - что значит не используйте UNION? Этож почти тоже самое что не используйте where, а то будет медленно :) Более осмысленно было бы порекомендовать что-то на замену.
Конечно. И иметь данные с сот.
Ну мы кстати пытались. Вот представь, что у тебя есть под рукой биллинг (по картам твоего банка). И в этом биллинге написано, что человек заплатил какому-то ООО Вася Пупкин (название латиницей, транслитерация) столько-то денег непонятно за что. Биллинг этот присылает тебе Visa, ну или в общем, некая карточная система, и составлен он по ее стандартам. И адрес там тоже написан так, что геокодировать его удается скажем в 80% случаев. Да, еще биллинг это терабайты в день, скажем, и работать с ним не так и просто чисто технически.
Короче говоря, если это POS терминал не принадлежит своему банку, то исследовать платежи даже в такой ситуации далеко не тривиально. Вплоть до того, что мы начали применять всякие эвристики типа того, что если платежи А и Б были произведены в течение 5 минут - значит POS Б (это например банк конкурент) находится где-то близко от POS А (который нашего банка, и мы даже знаем координаты), и мы можем примерно прикинуть, где этот POS стоит, даже не имея правильного адреса, ну или уточнить результат геокодирования. С кучей допущений, что человек скажем шел пешком, и за 5 минут удалился не более чем на ... (а если он на самокате?).
Даже будучи банком, это не так просто, не все удается определить, что может быть интересно. Удобнее всего когда у человека в кармане смартфон, и там стоит твое платежное приложение, и каждый платеж сопровождается координатами, помимо всего остального. Да и то остаются вопросы при платежах скажем за билет в трамвае ;) Ну или нужно сочетать данные банка, и скажем сотового провайдера - а это уже сложная задача, причем не технически.
А уж про обычного человека я и не говорю.