Вопрос, наскольким может быть эффективным, для снижения стоимости разработки пробной версии, такой подход, не писать с нуля, а соединять куски программ или целеком в зависимости от ТЗ?
А так часто и делают, MVP/PoC нередко представляет из себя некоего на коленке собранного кадавра, где конфигурация и пути к файлам зашиты прямо в код, вместо вызова библиотечных функций вызываются внешние приложения с передачей данных файлами... В итоге это может выглядить как приложенька, куда загружают фото котика, приложенька выводит породу котика, а потом требует перезапуска для следующей фотки. Саму возможность по фотке определять породу демонстрирует, ну и замечательно. Красиво и аккуратно будем писать тогда, когда решение о дальшейшей разработке проекта будет окончательно принято.
Но для непрограммистов подобное обычно ограничивается или NoCode-сервисами типа модных нынче workflow-конструкторов всяких телеграм-ботов, или тривиальными скриптами (либо bat-файлами), которые вызывают какие-то готовые программы. Для чего-то чуть-чуть более сложного придётся всё же хоть немного программировать. Даже если и на малознакомом языке (например, я слабо умею в js, но если надо - я как-нибудь смогу доработать какой-нибудь несложный скрипт,).
я думаю должно быть достаточно много хорошего кода... в открытом доступе.
К сожалению, плохого и даже отвратительного кода тоже очень и очень много... А чтобы ещё и компетентно отличить одно от другого, нужно хоть немного уметь программировать. Опять всё упирается в то, что без знания программирования практически никуда...
У меня по факту на руках проект который надо разработать за намного меньшую стоимость, чем если все с нуля прописывать.
Если проект действительно нереально разработать на имеющихся условиях, то лучше от него отказаться.
Варианты есть, конечно. Например, можно инвестировать из своих средств, если есть понимание, что эта разработка может быть продана ещё нескольким заказчикам. Можно пойти на работу в некоторый убыток по конкретному проекту, если это позволит получить прибыльного долгосрочного клиента. Но это надо прям иметь офигенную уверенность, чтобы не пускать деньги на ветер...
Как пример, мой работодатель сделал за свой счёт интеграцию с одним известным сервисом для мелких бизнесов под спецификацию API этого сервиса, это была неплохая стратегическая инвестиция, поскольку она привела нам сотни этих самых мелких клиентов. Сам сервис заявил, что интегрироваться с нашим собственным API он будет минимум полгода и небесплатно.
Бывают и менее удачные примеры. Например, мы разработали интеграцию с местным вьетнамским мессенджером Zalo. Но за 3 года ни одного клиента на этот мессенджер так и не появилось. Впрочем, у нас и клиентов из Вьетнама до сих пор нет. А этот мессенджер предлагает бизнес API только для бизнесов, у которых есть хотя бы представительство во Вьетнаме, так что для других стран он коммерчески неинтересен.
jolomo, атакуют не ssh сервера, атаке подвергаются другие сервера по ssh. Причём определить атаки на совсем чужие хосты хостер не может, но он видит, что с этого сервера идут попытки подбора пароля типичных словарных пользователей (admin, jenkins итд) на его собственные хосты.
Как ломают нельзя так просто определить. Либо клиенты из VPN (у кого-то из "друзей" зловред), либо злоумышленники нашли дырку где-то (например, в php-коде каком-нибудь) или внедрили эксплойт в код, который переезжает при переустановке сервера (например, в сайтике уже затесался постоянно живущий web shell).
kswapd0 означает, что чего-то в этот момент выжрало много памяти, больше чем есть на сервере. Если это виртуалка с малым количеством памяти, то пачка ssh-клиентов легко такое может устроить.
Операторы определяют использование сим-карты в модеме по двум признакам:
1. IMEI;
2. TTL пакетов.
По первому решается прошивкой в модеме IMEI из числа "телефонных" (например, от Nokia). Нужно сразу быть готовым, что операторы могут на этом основании начать себя вести особым образом. Например, мне на модем начали иногда кидать PUSH-рекламки, в которых модем автоматически соглашался с подпиской.
Разумеется, не всякий модем позволяет смену IMEI, но если данный оператор на IMEI полагается, то этот вариант стоит рассмотреть.
По второму пункту обычно проблемы бывают на модемах, где модем имеет отдельный IP и выступает роутером, там надо найти прошивку, которая будет TTL изменять для пакетов. Опять же, не всякий модем позволяет такое сделать. Либо надо пропатчить на стороне своей операционной системы, чтобы TTL исходящих пакетов был +1 от нужного.
Кстати кейс с Ростовом показательный: многие жители РнД напишут просто "Ростов", даже не задумываясь, что это другой город в другом месте :)
Из других примеров можно вспомнить Киров, которых как минимум два (в Калужской и Кировской губерниях).
В общем, если делать именно "точно", то проблема даже не в именительном падеже, а в получении адекватной базы населённых пунктов, распределённых по административно-территориальным единицам.
Можно налажать на показе один раз, два раза, даже три раза, но если это всё ещё продолжается, то это уже тревожный звоночек. Это значит, что в консерватории ничего не меняется, код не становится лучше, баги не исправляются, тестирование не проводится, сценарий показа не отрабатывается заранее. И самое главное, что не делаются выводы и не улучшаются процессы.
Если всё так плохо, то не надо вообще проект показывать, пока он всё ещё остаётся таким плохим. Ограничиться внутренними показами, внутри своего отдела или других отделов своей организации. Показывать специалистам из числа друзей. В конце концов, дать своей маме потыкать по кнопкам - пусть лучше она случайно найдёт ту самую, что делает delete without where и роняет приложение насмерть, чтобы это не случилось во время важного показа...
И уж точно не следует за неделю до показа рваться всё переделывать. Ничего хорошего не получится. Ведь программирование - это процесс добавления новых багов в программу. За программированием следует отладка, которая эти баги призвана устранить. Сколько именно новых багов появится от разработки в бешенном темпе с недельным дедлайном и сколько недель потребуется на их последующее исправление никогда нельзя предсказать, но что их будет немало - это даже к гадалке ходить не надо.
Вова, данный пример явно не из той оперы, рекомендую посмотреть другие его вопросы. Из массового же рыночного предложения работодатель вряд ли захочет брать кого-то на неполную ставку. Отвечающие всё правильно говорят: на такое могут согласиться ради сеньора-помидора с большим опытом и вау-навыками, показанными на собеседовании, а джуны всё равно почти никому не нужны.
Нормальных админов на серьзёную инфраструктуру у нас тоже очень подолгу ищут.
Зачем работодателю сотрудник на 4 рабочих дня, если он может просто его не брать и взамен взять сотрудника на 5 рабочих дней?
Нет, конечно, если выразивший желание работать по 4 дня в неделю за этот срок приносит пользу, как три обычных сотрудника... Но тут явно другой случай.
metalexs, естественно, я видел, что вопрос был не об этом. Тем не менее, я считаю необходимым предупредить, что идея - полное дерьмо. Писать ушедшим людям - самый идиотский способ их удержать. Ещё и рискованный.
RANTEN, ну конечно, если есть два одинаковых обработчика с одинаковыми условиями, то первый перехватывает всё. Нужно или сделать всё в одном обработчике, или сделать более узкие условия.
Например, можно что-нибудь в духе func=lambda call: call.data.startswith('A')
metalexs, хм... ну ок. Но тогда вопрос о том, как писать, возникать не должен. Но я не рекомендую писать вышедшим с канала пользователям, так как многие из них сразу же пожалуются на спам.
prixhd, я повторю то же самое, что написано выше: приведённый код подобную ошибку вызвать не может, так как main не является корутиной. Судя по всему, запускался какой-то другой код, где есть другая асинхронная функция main. На то же указывает и тот факт, что в приведённом фрагменте main не возвращает никаких результатов, никаких таких links.
RANTEN, кстати я думаю что понял где беда. Сразу после строчки "#ПРОБЛЕМА ЗДЕСЬ" нет @ перед декоратором, естественно, декоратор не работает, определяется обычная функция, которая потом нигде не вызывается.
Если я правильно понял, то средствами самого dialogflow никак нельзя выбрать язык. Надо спросить язык в самом боте до включения интеграции с dialogflow.
@belkin_aa
рекомендую также посмотреть в сторону биндингов к uno на питоне. У меня тут валяется старый скрипт ещё на python2 https://pastebin.com/K6FA0vRY , можно на его примере просто посмотреть как это делается. Да, не слишком удобно, но зато можно лучше управлять процессом.
Сам я отказался от uno, потому что мне обычно надо конвертить между xlsx и csv, а для этого есть нативные реализации намного более быстрые и удобные.
А так часто и делают, MVP/PoC нередко представляет из себя некоего на коленке собранного кадавра, где конфигурация и пути к файлам зашиты прямо в код, вместо вызова библиотечных функций вызываются внешние приложения с передачей данных файлами... В итоге это может выглядить как приложенька, куда загружают фото котика, приложенька выводит породу котика, а потом требует перезапуска для следующей фотки. Саму возможность по фотке определять породу демонстрирует, ну и замечательно. Красиво и аккуратно будем писать тогда, когда решение о дальшейшей разработке проекта будет окончательно принято.
Но для непрограммистов подобное обычно ограничивается или NoCode-сервисами типа модных нынче workflow-конструкторов всяких телеграм-ботов, или тривиальными скриптами (либо bat-файлами), которые вызывают какие-то готовые программы. Для чего-то чуть-чуть более сложного придётся всё же хоть немного программировать. Даже если и на малознакомом языке (например, я слабо умею в js, но если надо - я как-нибудь смогу доработать какой-нибудь несложный скрипт,).
К сожалению, плохого и даже отвратительного кода тоже очень и очень много... А чтобы ещё и компетентно отличить одно от другого, нужно хоть немного уметь программировать. Опять всё упирается в то, что без знания программирования практически никуда...
Если проект действительно нереально разработать на имеющихся условиях, то лучше от него отказаться.
Варианты есть, конечно. Например, можно инвестировать из своих средств, если есть понимание, что эта разработка может быть продана ещё нескольким заказчикам. Можно пойти на работу в некоторый убыток по конкретному проекту, если это позволит получить прибыльного долгосрочного клиента. Но это надо прям иметь офигенную уверенность, чтобы не пускать деньги на ветер...
Как пример, мой работодатель сделал за свой счёт интеграцию с одним известным сервисом для мелких бизнесов под спецификацию API этого сервиса, это была неплохая стратегическая инвестиция, поскольку она привела нам сотни этих самых мелких клиентов. Сам сервис заявил, что интегрироваться с нашим собственным API он будет минимум полгода и небесплатно.
Бывают и менее удачные примеры. Например, мы разработали интеграцию с местным вьетнамским мессенджером Zalo. Но за 3 года ни одного клиента на этот мессенджер так и не появилось. Впрочем, у нас и клиентов из Вьетнама до сих пор нет. А этот мессенджер предлагает бизнес API только для бизнесов, у которых есть хотя бы представительство во Вьетнаме, так что для других стран он коммерчески неинтересен.