В том то и дело, что в экстремальной ситуации у Вас не будет времени разбираться рык или не рык. Кто может рычать в пустыне - вроде и никто, или же есть 1% шанс что всё таки хищник.
Согласен с Вами, что если опасность очевидная то и решение будет принято наиболее правильное. Но когда есть неизвестный аргумент, решение организм способен выдать не самое рациональное :)
На самом деле, тот факт что бы упускаем риск в 99.9% обосновывается по тому же пути что и тревожное расстройство, одним словом - эволюция.
Из книги "Хорошие плохие чувства" (мой пересказ):
Если вы обезвоженный идете по пустыне и слышите рык где-то збоку от вас. Что это? Что делать? Показалось?
С этой ситуации всего два пути :
- Бежать, бежать и не оглядываться. Плюс : избегаете вероятность в 1% что там реально был хищник. Минусы : и без того обезвоженый организм будет подтвергнут таким нагрузкам, что вероятность выжывания близитса к 0.
- Забить на звук и продолжать движение в том же темпе. Плюс : то малое количество влаги, что есть в организме сохраняется и шанс на выживание остаеться на том же уровне. Минусы : с вероятностью в 1% вас сьест хищник.
Что выберет человек? Доказано эволюцией (нашим существованием) что даже если из 100 случаев, всего 1 окажется фатальным, мы не станем играть в лотерею, даже если в 99 случаев попытка бежать будет смертельной и безрассудной, наш организм, мозг и инстинкт размножения и выживания будет давать команду бежать.
Так же и здесь, несмотря на очевидную возможность потерять деньги в 99.9% случаев, мы думаем о том, что на самом деле мы теряем возможность потерять деньги(в 0.1%) если остановимся.
Но рано или поздно наступает такой момент, когда стоимость использования технологии превышает прибыль от её применения
А откуда вы знаете что прибыль может быть больше? Предположу, что можно подсмотреть у тех, кто уже внедрил новую технологию. Тогда возникает резонный вопрос ценностей для вашей компании. Не хочу показаться душным, но ведь у более ранних версиях ПО свои парадигмы на которых они строятся. Если убирать из стула мягкую подушку, с целью увеличить прибыль и уменшить расходы то сидеть останеться на ...
" Взять банальный пример с сериалами, первый сезон всегда лучше второго, третьего И так далее. "
Спасибо автору, очень много новых взглядов для меня открылось от прочтения такой небольшой статьи.
После прочтения, особенно последних слов у меня возник вопрос к автору, ссылаясь на цитату:
но гораздо больше его беспокоит мир, в котором люди не верят ничему, кроме своих предубеждений.
Насколько мне известно, статистика рассматривает не отдельно взятый случай, а количество таких случаев на 100 человек, на 1000 человек. Исходя из такого принципа, статистика полезная при работе с обществом или кругом лиц. В собственных действиях и поступках не лучше ли полагаться на предубеждения?
Например, если смотреть в абстракции, прививка от ковида, это полезно и тебе и обществу. Но занятия спортом, например, хоть статистически и показывают положительное влияние, но, как пример с курящей бабушкой и не курящим больным раком, это никоем образом не оберегает тебя от болезней.
Удобней в рамках небольшого функционала, когда вы знаете какие наверняка ключи содержит массив (по памяти). По опыту скажу что когда изначально используешь хранения в массивах и допустим, не заходишь в приложение больше недели, то нужно напрягаться и вспоминать какие там ключи есть в массиве. Это если не затрагивать тему совместной разработки или OpenSource.
Думать о будущем стоит на начальных этапах проектировки, люди же не строят дом без утепления только потому что строят летом и не холодно. Стараются утеплять на зиму, тоесть заблаговременно.
И я обращал ваше внимание не на тот массив который вы создаете, а тот который получаете. Про парсинг входящей строки, если вы интегрируетесь с API и знаете что будете использовать именно эту API, то представьте какие бы вы получили возможности создав по крайней мере один класс в котором реализовали бы функции например toArray и toStd и каждый раз когда получили бы ответ от сервера, этот ответ бы превращался в класс с которым удобно работать и с которого можно получать данные путем обращения к свойствам класса. Кроме того какой то начальные парсинг входящих строк, json blob и так далее можно реализовать прямо там, таким образом детально декомпозировав логику.
Спасибо за ваше уточнение :)Не знал про case в Python вообще, говорил с точки зрения большинства так сказать :)
P.S. в пункте 3 хотел суть передать в лаконичном сообщении, туда же по-хорошему DRY, KISS. Абстракция тоже пригодилась бы, а то получается автор обращается к некоторым ключам используя выражения типа :
json_data[0]['MobileLink']
Когда такая запись имеет место быть в том случае, если массив больше не содержит полезной нагрузки и в будущем будет использоваться только ради этого одного ключа (если мы говорим, о том, что внешний ресурс не имеет конечных точек для конкретно этого параметра). В коде автора же, буквально несколькими строками ниже, используется выражения типа :
json_data[0]['Temperature']['Value']
P.P.S. Я хотел аргументировать свои предложение фактическими кейсами, а не придираться к вырванному из всего кода обращению к массиву.
Нет, я имею в виду что предоставлю username, hostname, password в консоли для того что бы попасть через ssh тунель на сервер.
И да, файл вы так не скопируете.
Не соглашусь, файл отлично копируется через ssh соеденение на сервер и с сервера, да и автор статьи использует терминал команду scp для копирования файлов через терминал (консоль). Там же вводить пароль.
Открываем командную строку в виндовс
pscp -P (здесь указываем порт джино) C:\(путь к проекту)\ root@"указываем имя сервера":/usr/bin/telebot/
Он попросит ввести пароль, вводим пароль от root.
Вы вообще читали статью?
UPD.:
зачем пользоваться веб-интерфейсом когда Putty есть
Putty может как файловый менеджер и более наглядная штука, но задеплоить проект на сервер проще через одну команду в терминале, не нужно ничего открывать, устанавливать И так далее. Своими ручками нужно уметь.
Хранить токены к ресурсам в коде - такое себе занятие :)
Зачем вы пишете что нужно Putty и упоминаете это приложение, если по факту - не используете и перекидываете на сервер используя bash?
Код стайл обязательно стоит изучит. Начните с того, что бы называть переменные не транслитом, а по назначению, на английском и использовать вместо большых if условий, switch операторы.
Зачем в тестовых целях арендовать вообще сервер? Не проще ли (и дешевле) тестовые проекты любому человеку делать на локалке... С другой стороны конечно хорошо что показали как заливать приложения на выбранный вами сервис, но урок ведь не про это. Ссылаясь на ваши собственные слова :
инструкций по созданию телеграмм-бота полно в интернете
Но если сказать в позитиве эти же фразы то всё выглядит не так уж и плохо.
Например :
1. Очень нестабильный шрифт
Шрифт, который ещё нужно декодировать :) секьюрность на уровне :)
2. Далее всё остальное множество неудобств из-за «не цифровой» природы записей.
В отличии от цифровых аналогов записей которые всегда в облаке или на вашем ноутбуке - бумажные записи предоставляют уникальный опыт в сравнении с обычным режимом работы на клавиатуре, можно отвлечься глазами и руками.
но, говоря откровенно, мой коммент уже попахивает придирками. Каждый выбирает конечно же то, что ему ближе. Лично я работаю и так за компьютером слишком много времени, сидеть и смотреть в экран, отвлекаюсь на заметку альтабом ухудшает положение. А так это как глоток воздуха :)
И система поиска по бумажным заметкам очень похожа на электронную.
Круто когда есть интересная книжка на чтение, а ещё круче когда после этой книжки есть ещё 4. Спасибо за подборку, хочу прочитать про заметки, надеюсь начну записывать наконец-то план на день :)
В команде процесс код ревью растягивал релиз на +1 или +2 недели, часто давали заниженный эстимейт. Как результат : негативный фидбек от клиента и настроение команды.
Решение :
Взяли за правило добавлять 20% от начального эстимейта в качестве буфера для код ревью. Да, шанс промахнутся из-за код ревью остался, но разница будет существенно ниже. Как результат : время на ревью больше, результат ревью качественней, команда в положительном настроении, клиент не переживает.
Полезные заметки по процессу и путях улучшения Code Review. Не хватает реального опыта вместо теории. А то у нас в команде процесс ревью - это скорее то, что никто не хочет делать (скучно) и если бы автор поделился реальным опытом, о том как сделает проще и быстрее, то эта статья была бы гораздо полезнее.
Да нету толку делать проекты с неопределённым тех.стеком. А вот калькулятор все делали, и подскажут и посмотреть есть куда. В этом и смысл же обучения.
А насчёт пэт-проектов если уже есть база - согласен с Вами, стоит делать для себя или для команды если есть такая возможность. Даже если тот же мессенджер, но такой какой Вы хотите с функционалом которого Вам и не хватает.
Почему же люди учатся разговаривать на всем понятном языке, а не изобретают свой что бы его знало пара человек ?
Да и что значит никому не нужный калькулятор если человек учится только. Результатом таких проектов станут изученные методы и технологии, а никак не продукт.
Как раз девушка заинтересовалась frontend, говорю ей - делай проекты свои, тренируйся на них. А вот какие проекты, где взять идеи? Эта статья - отличный источник таких идей, для начинающего разработчика (опытный скорее всего уже имеет за собой тележку с пет-проектами). P.S. хорошо что описано технологии которыми научишься в процессе выполнения и функционал который нужно реализовать.
Инструмент который решает конкретную проблему, однозначно решение годное и перспективное!
Упростить бы workflow процесса для людей которые только познают проектирование системы, допустим ещё на своих пет-проектах. Как результат - увеличили бы аудиторию и покрытие, а в будущем эти же бы юзеры столкнулись с проблемами которые как раз таки и решаются с помощью вашего приложения и никуда не нужно было бы идти (уже на месте всё)!
В том то и дело, что в экстремальной ситуации у Вас не будет времени разбираться рык или не рык. Кто может рычать в пустыне - вроде и никто, или же есть 1% шанс что всё таки хищник.
Согласен с Вами, что если опасность очевидная то и решение будет принято наиболее правильное. Но когда есть неизвестный аргумент, решение организм способен выдать не самое рациональное :)
На самом деле, тот факт что бы упускаем риск в 99.9% обосновывается по тому же пути что и тревожное расстройство, одним словом - эволюция.
Из книги "Хорошие плохие чувства" (мой пересказ):
Так же и здесь, несмотря на очевидную возможность потерять деньги в 99.9% случаев, мы думаем о том, что на самом деле мы теряем возможность потерять деньги(в 0.1%) если остановимся.
А откуда вы знаете что прибыль может быть больше? Предположу, что можно подсмотреть у тех, кто уже внедрил новую технологию. Тогда возникает резонный вопрос ценностей для вашей компании. Не хочу показаться душным, но ведь у более ранних версиях ПО свои парадигмы на которых они строятся. Если убирать из стула мягкую подушку, с целью увеличить прибыль и уменшить расходы то сидеть останеться на ...
" Взять банальный пример с сериалами, первый сезон всегда лучше второго, третьего И так далее. "
Спасибо автору, очень много новых взглядов для меня открылось от прочтения такой небольшой статьи.
После прочтения, особенно последних слов у меня возник вопрос к автору, ссылаясь на цитату:
Насколько мне известно, статистика рассматривает не отдельно взятый случай, а количество таких случаев на 100 человек, на 1000 человек. Исходя из такого принципа, статистика полезная при работе с обществом или кругом лиц. В собственных действиях и поступках не лучше ли полагаться на предубеждения?
Например, если смотреть в абстракции, прививка от ковида, это полезно и тебе и обществу. Но занятия спортом, например, хоть статистически и показывают положительное влияние, но, как пример с курящей бабушкой и не курящим больным раком, это никоем образом не оберегает тебя от болезней.
Уже отвечали в комментариях что есть, с недавнего апдейта
Удобней в рамках небольшого функционала, когда вы знаете какие наверняка ключи содержит массив (по памяти). По опыту скажу что когда изначально используешь хранения в массивах и допустим, не заходишь в приложение больше недели, то нужно напрягаться и вспоминать какие там ключи есть в массиве. Это если не затрагивать тему совместной разработки или OpenSource.
Думать о будущем стоит на начальных этапах проектировки, люди же не строят дом без утепления только потому что строят летом и не холодно. Стараются утеплять на зиму, тоесть заблаговременно.
И я обращал ваше внимание не на тот массив который вы создаете, а тот который получаете. Про парсинг входящей строки, если вы интегрируетесь с API и знаете что будете использовать именно эту API, то представьте какие бы вы получили возможности создав по крайней мере один класс в котором реализовали бы функции например toArray и toStd и каждый раз когда получили бы ответ от сервера, этот ответ бы превращался в класс с которым удобно работать и с которого можно получать данные путем обращения к свойствам класса. Кроме того какой то начальные парсинг входящих строк, json blob и так далее можно реализовать прямо там, таким образом детально декомпозировав логику.
Спасибо за ваше уточнение :)Не знал про case в Python вообще, говорил с точки зрения большинства так сказать :)
P.S. в пункте 3 хотел суть передать в лаконичном сообщении, туда же по-хорошему DRY, KISS. Абстракция тоже пригодилась бы, а то получается автор обращается к некоторым ключам используя выражения типа :
Когда такая запись имеет место быть в том случае, если массив больше не содержит полезной нагрузки и в будущем будет использоваться только ради этого одного ключа (если мы говорим, о том, что внешний ресурс не имеет конечных точек для конкретно этого параметра). В коде автора же, буквально несколькими строками ниже, используется выражения типа :
P.P.S. Я хотел аргументировать свои предложение фактическими кейсами, а не придираться к вырванному из всего кода обращению к массиву.
ну допустим, сможете увидеть, если сзади Вас человек, который стоит к банкомату в очереди, начнет снимать Вас на видео?
Нет, я имею в виду что предоставлю username, hostname, password в консоли для того что бы попасть через ssh тунель на сервер.
Не соглашусь, файл отлично копируется через ssh соеденение на сервер и с сервера, да и автор статьи использует терминал команду
scpдля копирования файлов через терминал (консоль). Там же вводить пароль.Вы вообще читали статью?
UPD.:
Putty может как файловый менеджер и более наглядная штука, но задеплоить проект на сервер проще через одну команду в терминале, не нужно ничего открывать, устанавливать И так далее. Своими ручками нужно уметь.
Введу пароль в консоли…
Хранить токены к ресурсам в коде - такое себе занятие :)
Зачем вы пишете что нужно Putty и упоминаете это приложение, если по факту - не используете и перекидываете на сервер используя bash?
Код стайл обязательно стоит изучит. Начните с того, что бы называть переменные не транслитом, а по назначению, на английском и использовать вместо большых if условий, switch операторы.
Зачем в тестовых целях арендовать вообще сервер? Не проще ли (и дешевле) тестовые проекты любому человеку делать на локалке... С другой стороны конечно хорошо что показали как заливать приложения на выбранный вами сервис, но урок ведь не про это. Ссылаясь на ваши собственные слова :
Удачи в новых проектах!
Но если сказать в позитиве эти же фразы то всё выглядит не так уж и плохо.
Например :
Шрифт, который ещё нужно декодировать :) секьюрность на уровне :)
В отличии от цифровых аналогов записей которые всегда в облаке или на вашем ноутбуке - бумажные записи предоставляют уникальный опыт в сравнении с обычным режимом работы на клавиатуре, можно отвлечься глазами и руками.
но, говоря откровенно, мой коммент уже попахивает придирками. Каждый выбирает конечно же то, что ему ближе. Лично я работаю и так за компьютером слишком много времени, сидеть и смотреть в экран, отвлекаюсь на заметку альтабом ухудшает положение. А так это как глоток воздуха :)
И система поиска по бумажным заметкам очень похожа на электронную.
А что не так с письмом от руки, свой шрифт как бы :)
Круто когда есть интересная книжка на чтение, а ещё круче когда после этой книжки есть ещё 4. Спасибо за подборку, хочу прочитать про заметки, надеюсь начну записывать наконец-то план на день :)
Опыт автоматизации, примеры проблема - решение.
Был бы интересен такой формат :
Проблема :
Решение :
Полезные заметки по процессу и путях улучшения Code Review.
Не хватает реального опыта вместо теории.
А то у нас в команде процесс ревью - это скорее то, что никто не хочет делать (скучно) и если бы автор поделился реальным опытом, о том как сделает проще и быстрее, то эта статья была бы гораздо полезнее.
Да нету толку делать проекты с неопределённым тех.стеком. А вот калькулятор все делали, и подскажут и посмотреть есть куда. В этом и смысл же обучения.
А насчёт пэт-проектов если уже есть база - согласен с Вами, стоит делать для себя или для команды если есть такая возможность. Даже если тот же мессенджер, но такой какой Вы хотите с функционалом которого Вам и не хватает.
Почему же люди учатся разговаривать на всем понятном языке, а не изобретают свой что бы его знало пара человек ?
Да и что значит никому не нужный калькулятор если человек учится только. Результатом таких проектов станут изученные методы и технологии, а никак не продукт.
Как раз девушка заинтересовалась frontend, говорю ей - делай проекты свои, тренируйся на них. А вот какие проекты, где взять идеи? Эта статья - отличный источник таких идей, для начинающего разработчика (опытный скорее всего уже имеет за собой тележку с пет-проектами).
P.S. хорошо что описано технологии которыми научишься в процессе выполнения и функционал который нужно реализовать.
Инструмент который решает конкретную проблему, однозначно решение годное и перспективное!
Упростить бы workflow процесса для людей которые только познают проектирование системы, допустим ещё на своих пет-проектах. Как результат - увеличили бы аудиторию и покрытие, а в будущем эти же бы юзеры столкнулись с проблемами которые как раз таки и решаются с помощью вашего приложения и никуда не нужно было бы идти (уже на месте всё)!