В примере с Django не будет ли оптимальнее использовать такой вариант? Если "переедете" на собственную модель пользователя, будет меньше работы по рефакторингу ) from django.contrib.auth import get_user_model User = get_user_model()
Эх, было бы еще здорово по факту каждого прогноза выполнять post mortem: "сбылось", "не сбылось", "сбылось ровно наоборот" и в итоге накапливать статистику по степени доверия их авторам, дабы отделить "агнцев от козлищ".
Jason Fried в целом не боится плыть "против течения" по самым разным вопросам: - суппортят все (!) версии своего ПО и не заставляют пользователей обновляться; - в прошлом году переехали из арендуемого облака на собственные сервера; - бюджет вакансий озвучивается гласно и не зависит от местоположения работника; - последовательно описывает свои принципы (а также преимущества и факапы, которые они ему приносят) в книгах в соавторстве с совладельцем 37signals - датчанином David Heinemeier Hansson. Единственное, о чем жалею - не узнал о творчестве лет десять назад.
Исключительно субъективные pro et contra: + информации по странам больше, чем в той же pycountry. - но частота обновления данных не очень высокая (на примере РФ - 4 года назад; понятно, что столица и валюта не изменились, но данные по населению отчетливо устарели); + но вся информация идет "на борту" вместе с либой в виде пучка джейсонов (если кому прямо сильно надо актуализировать - редактор в руки); - но как добавить страну, непонятно (тот же Северный Кипр формально не существует, а реально - вполне). В любом случае, спасибо контрибьюторам за проект, а автору - за статью :)
Самое значимое (IMHO) нововведение во второй версии - это то, что BPMN стал исполнимым. То есть синтаксически корректное описание, выполненное в нормальном редакторе (например, Camunda вместо draw.io или Visio), может быть сохранено* в виде исполнимой модели, верифицировано и выполнено. Так БА получает возможность "поиграться в процесс" до того, как он будет реализован непосредственно в коде. * Описание сохраняется в machine-readable XML, а картинки с дорожками, событиями и прочими стрелочками - это просто визуализация для человеков. Хотя тоже полезно для достижения ими единого видения этого самого процесса :)
Проблема многих курсов в том, что они фокусируются на инструменте. "Вот сейчас мы запилим клон YouTube" - и айда кодить вовсю. А то, что огромный кусок работы (начиная с UI/UX, use cases, проектирования архитектуры, структуры БД, структуры API, непосредственно выбор инструментария) должен быть выполнен до всего этого и не меньший (rollout, performance, backup, maintenance etc.) после этого - скромно опускается. Хорошо, если автор про тесты не забудет и вскользь упомянет про CI/CD. В итоге все получается как у Майка Тайсона: "У каждого есть план до первого удара в челюсть" (в нашем случае до первого реального проекта). И вот тут-то начинается реальная жизнь :)
Возможно это конструктивное требование вызвано схемой расположения кассет (с банкнотами + выбраковки) и механизма их передачи. Обычно кассеты стоят "стопкой" друг над другом (от 2 до шести штук), а механизм - рядом.
Судя по отсутствию комментариев - то ли ни у кого не было факапов, то ли никто не хочет о них вспоминать. А ведь это считай самая мощная (хотя и болезненная, конечно) точка роста. Итого навскидку: 1. Разработка продукта - вместо MVP было решено сразу делать полнофункциональную версию. Потому что "оно же не может не выстрелить"(с) маркетологи. В итоге пока поняли, что оно все же не выстреливает - потратили несколько человеко-лет. Выводы? "Fail fast approach" для всех последующих гениальных идей. 2. Разработка изначально коробочного продукта, первое внедрение у крупного заказчика (aka "наше все"), который в итоге формировал основной cash flow для команды. Тот же, пользуясь своим положением, раз за разом продавливал развитие "коробки" под свои процессы. Что имеем в итоге? Кастомный продукт и отставание от продуктов-конкурентов. Выводы? Ориентироваться не на конкретного контрагента, а на рынок целиком. 3. "Резиновое ТЗ" - для заказчика, уже имевшего в эксплуатации несколько других наших продуктов, делали очередную систему. Уже после разработки и внедрения (все согласно BRD и ТЗ) заказчик мелкими запросами "давайте вот тут еще чуть-чуть добавим / а мы имели в виду еще и вот это / у нас тут слегка полностью поменялись процессы" продавил еще примерно половину изначальной трудоемкости внутри того же бюджета. Выводы? Фиксировать все договоренности как SMART-задачи, допускающие минимальную вероятность двойного толкования. Полный перенос рисков на сторону исполнителя - путь в никуда и лучше на него не становиться. PS Сейчас, если по завершении проекта мне кажется что все прошло как по маслу - напрягаюсь еще больше, так как скорее всего упускаю что-то глобальное :)
Проблема в том, что критерии полноценности подписи могут быть разные ("простая", "усиленная неквалифицированная", "усиленная квалифицированная") Например: - внутри организации Вы можете принять ЛНПА, который приравнивает наличие простой электронной подписи к бумажной, если это не противоречит законодательству для конкретного вида документа (например, внутренние документы вроде заявки на доступ и т.д.); - Вы можете согласовать с контрагентами вариант использования усиленной неквалифицированной подписи (как минимум чтобы получатель был уверен, что документ подписан конкретным исполнителем и не был изменен при пересылке); - но в случае обмена с госорганами и для приличного числа видов документов Вам все же будет нужна усиленная квалифицированная подпись, которую выдает аккредитованный удостоверяющий центр. И вот тут начинается самое интересное.
По системам - open-source вполне может работать с подписями первых двух типов. А вот третий - это чистой воды проприетарщина плюс еще уникальная для каждой юрисдикции. Я с трудом представляю сообщество, которое решит тратить свои ресурсы на такую проблему. Как вариант - брать OSS EDMS, брать провайдера ЭЦП с хорошо документированным API - и пилить интеграцию (своими руками или аутсорсить). Или искать того, кто это уже сделал. В любом случае придется заплатить. Пример первых двух подходов - https://docs.mayan-edms.com/chapters/signatures.html Пример третьего - та же "Логика Бизнеса" на платформе Alfresco.
В целом в тексте как раз сказано, что внутренняя мотивация эффективнее внешней. Статья же вполне адекватна и по существу - создай себе "мотив + средство + возможность" и успех неминуем )
В то время и фотоаппараты, и телефоны отражали индивидуальное видение своих создателей на то, как форма устройства должна соответствовать его содержанию. F717/F828 были легендарными аппаратами, а Sony R1 и сейчас выглядит интересно.
PS Дальше всех по пути творческого поиска, наверное, вообще ушли Ricoh со своим GRX-"конструктором" )
Коллеги, описываемая в тексте специальность правильно читается не как "ИТ-архитектор", а именно как "IT-архитектор low-code платформы Pega". Омонимия конечно довольно странная - но не изобретение АБР ) Вон, сам вендор предлагал в свое время обучить этому делу за (внимание) 2 дня 2 часа и 45 минут: https://academy.pega.com/mission/system-architect/v1
Статья о том, как специалист по репутации в интернете быстро и умело похоронил свою репутацию в рамках отдельного ресурса. Если это были мошенники - они просто откроются под новым именем. Если люди работали по совести - то зарекутся впредь это делать. Такая вот lose-lose стратегия...
Банковское ИТ - своеобразное "племя отверженных": вроде как и не чистые банкиры (ИТ часто считается не зарабатывающим, а "бюджетным" подразделением - наряду с аудитом, безопасностью, хозяйственниками и т.д.) и часто "true IT" из продукта и/или аутсорса считают их как бы и не совсем ИТ.
В результате получается ситуация в стиле "недопереполз", которая усугубляется не всегда конкурентными рейтами, кучей бюрократии (в статье об этом не говорится - а зря) и подковерных интриг, зачастую непрозрачными процессами (хотя снаружи банки кажутся весьма солидными организациями) - и пресловутым отсутствием профессионального роста. Называть в качестве причины ухода оплату труда - это наиболее цифровой (а потому наименее личностный) вариант - намного проще, чем объяснять настоящие причины.
В итоге реальная ситуация может намного сложнее и запутаннее, чем показывает опрос. Поэтому если у программы будет "выхлоп" - респект вам, коллеги. Если нет - уверен, в процессе все участники получат интересный опыт :) Кстати, есть небольшой вопрос автору - в KPI функциональных руководителей учитывается текучка подчиненных?
Что же тогда делать простому индивидуальному инвестору в эти смутные времена? Складировать облигации госзаймов, которые всегда считались "тихой гаванью" или купить "на все" индексных фондов с максимальным региональным охватом, вцепиться в них как клещ и ждать, ждать, ждать...?
Если не секрет, как удалось провезти его в страну? Сам Amazon в РФ/РБ не доставляет. Заказал через посредника - теперь не могу вывезти его из Штатов (DHL не возит в РФ/РБ, USPS и AirMail не хотят связываться с перевозкой в самолете устройства с Li-Ion батареей). Уже убил на доставку ровно стоимость самого планшета - а "воз" и ныне "там" :(
Отличный текст, спасибо. Жду следующую статью :) PS Правильно ли я понимаю, что для каждого пользователя фактически создается его личный кабинет с возможностью просмотра его собственных фотографий? Если да, то не планируется (если вообще это возможно) ли сделать там интеграцию с соцсетями? Навроде сценария: "Ух, какой классный кадр! Бахну как я его себе в <тут_некая_соцсеть>"
В примере с Django не будет ли оптимальнее использовать такой вариант?
Если "переедете" на собственную модель пользователя, будет меньше работы по рефакторингу )
from django.contrib.auth import get_user_model
User = get_user_model()
Эх, было бы еще здорово по факту каждого прогноза выполнять post mortem: "сбылось", "не сбылось", "сбылось ровно наоборот" и в итоге накапливать статистику по степени доверия их авторам, дабы отделить "агнцев от козлищ".
Jason Fried в целом не боится плыть "против течения" по самым разным вопросам:
- суппортят все (!) версии своего ПО и не заставляют пользователей обновляться;
- в прошлом году переехали из арендуемого облака на собственные сервера;
- бюджет вакансий озвучивается гласно и не зависит от местоположения работника;
- последовательно описывает свои принципы (а также преимущества и факапы, которые они ему приносят) в книгах в соавторстве с совладельцем 37signals - датчанином David Heinemeier Hansson.
Единственное, о чем жалею - не узнал о творчестве лет десять назад.
Исключительно субъективные pro et contra:
+ информации по странам больше, чем в той же pycountry.
- но частота обновления данных не очень высокая (на примере РФ - 4 года назад; понятно, что столица и валюта не изменились, но данные по населению отчетливо устарели);
+ но вся информация идет "на борту" вместе с либой в виде пучка джейсонов (если кому прямо сильно надо актуализировать - редактор в руки);
- но как добавить страну, непонятно (тот же Северный Кипр формально не существует, а реально - вполне).
В любом случае, спасибо контрибьюторам за проект, а автору - за статью :)
Самое значимое (IMHO) нововведение во второй версии - это то, что BPMN стал исполнимым. То есть синтаксически корректное описание, выполненное в нормальном редакторе (например, Camunda вместо draw.io или Visio), может быть сохранено* в виде исполнимой модели, верифицировано и выполнено. Так БА получает возможность "поиграться в процесс" до того, как он будет реализован непосредственно в коде.
* Описание сохраняется в machine-readable XML, а картинки с дорожками, событиями и прочими стрелочками - это просто визуализация для человеков. Хотя тоже полезно для достижения ими единого видения этого самого процесса :)
Проблема многих курсов в том, что они фокусируются на инструменте. "Вот сейчас мы запилим клон YouTube" - и айда кодить вовсю.
А то, что огромный кусок работы (начиная с UI/UX, use cases, проектирования архитектуры, структуры БД, структуры API, непосредственно выбор инструментария) должен быть выполнен до всего этого и не меньший (rollout, performance, backup, maintenance etc.) после этого - скромно опускается. Хорошо, если автор про тесты не забудет и вскользь упомянет про CI/CD.
В итоге все получается как у Майка Тайсона: "У каждого есть план до первого удара в челюсть" (в нашем случае до первого реального проекта). И вот тут-то начинается реальная жизнь :)
Возможно это конструктивное требование вызвано схемой расположения кассет (с банкнотами + выбраковки) и механизма их передачи. Обычно кассеты стоят "стопкой" друг над другом (от 2 до шести штук), а механизм - рядом.
Судя по отсутствию комментариев - то ли ни у кого не было факапов, то ли никто не хочет о них вспоминать. А ведь это считай самая мощная (хотя и болезненная, конечно) точка роста.
Итого навскидку:
1. Разработка продукта - вместо MVP было решено сразу делать полнофункциональную версию. Потому что "оно же не может не выстрелить"(с) маркетологи. В итоге пока поняли, что оно все же не выстреливает - потратили несколько человеко-лет.
Выводы? "Fail fast approach" для всех последующих гениальных идей.
2. Разработка изначально коробочного продукта, первое внедрение у крупного заказчика (aka "наше все"), который в итоге формировал основной cash flow для команды. Тот же, пользуясь своим положением, раз за разом продавливал развитие "коробки" под свои процессы. Что имеем в итоге? Кастомный продукт и отставание от продуктов-конкурентов.
Выводы? Ориентироваться не на конкретного контрагента, а на рынок целиком.
3. "Резиновое ТЗ" - для заказчика, уже имевшего в эксплуатации несколько других наших продуктов, делали очередную систему. Уже после разработки и внедрения (все согласно BRD и ТЗ) заказчик мелкими запросами "давайте вот тут еще чуть-чуть добавим / а мы имели в виду еще и вот это / у нас тут слегка полностью поменялись процессы" продавил еще примерно половину изначальной трудоемкости внутри того же бюджета.
Выводы? Фиксировать все договоренности как SMART-задачи, допускающие минимальную вероятность двойного толкования. Полный перенос рисков на сторону исполнителя - путь в никуда и лучше на него не становиться.
PS Сейчас, если по завершении проекта мне кажется что все прошло как по маслу - напрягаюсь еще больше, так как скорее всего упускаю что-то глобальное :)
А если ты выбираешь ответы с зеленой галочкой - это уже признак middle? )
OSS это не есть синоним "бесплатно" )
Проблема в том, что критерии полноценности подписи могут быть разные ("простая", "усиленная неквалифицированная", "усиленная квалифицированная")
Например:
- внутри организации Вы можете принять ЛНПА, который приравнивает наличие простой электронной подписи к бумажной, если это не противоречит законодательству для конкретного вида документа (например, внутренние документы вроде заявки на доступ и т.д.);
- Вы можете согласовать с контрагентами вариант использования усиленной неквалифицированной подписи (как минимум чтобы получатель был уверен, что документ подписан конкретным исполнителем и не был изменен при пересылке);
- но в случае обмена с госорганами и для приличного числа видов документов Вам все же будет нужна усиленная квалифицированная подпись, которую выдает аккредитованный удостоверяющий центр. И вот тут начинается самое интересное.
По системам - open-source вполне может работать с подписями первых двух типов. А вот третий - это чистой воды проприетарщина плюс еще уникальная для каждой юрисдикции. Я с трудом представляю сообщество, которое решит тратить свои ресурсы на такую проблему. Как вариант - брать OSS EDMS, брать провайдера ЭЦП с хорошо документированным API - и пилить интеграцию (своими руками или аутсорсить). Или искать того, кто это уже сделал. В любом случае придется заплатить.
Пример первых двух подходов - https://docs.mayan-edms.com/chapters/signatures.html
Пример третьего - та же "Логика Бизнеса" на платформе Alfresco.
В целом в тексте как раз сказано, что внутренняя мотивация эффективнее внешней.
Статья же вполне адекватна и по существу - создай себе "мотив + средство + возможность" и успех неминуем )
В то время и фотоаппараты, и телефоны отражали индивидуальное видение своих создателей на то, как форма устройства должна соответствовать его содержанию. F717/F828 были легендарными аппаратами, а Sony R1 и сейчас выглядит интересно.
PS Дальше всех по пути творческого поиска, наверное, вообще ушли Ricoh со своим GRX-"конструктором" )
Коллеги, описываемая в тексте специальность правильно читается не как "ИТ-архитектор", а именно как "IT-архитектор low-code платформы Pega". Омонимия конечно довольно странная - но не изобретение АБР )
Вон, сам вендор предлагал в свое время обучить этому делу за (внимание) 2 дня 2 часа и 45 минут: https://academy.pega.com/mission/system-architect/v1
Будет здорово, если результат инициативы доберется до нормальной промышленной эксплуатации. Шаи-Хулуд такое бы одобрил )
Статья о том, как специалист по репутации в интернете быстро и умело похоронил свою репутацию в рамках отдельного ресурса.
Если это были мошенники - они просто откроются под новым именем. Если люди работали по совести - то зарекутся впредь это делать. Такая вот lose-lose стратегия...
Банковское ИТ - своеобразное "племя отверженных": вроде как и не чистые банкиры (ИТ часто считается не зарабатывающим, а "бюджетным" подразделением - наряду с аудитом, безопасностью, хозяйственниками и т.д.) и часто "true IT" из продукта и/или аутсорса считают их как бы и не совсем ИТ.
В результате получается ситуация в стиле "недопереполз", которая усугубляется не всегда конкурентными рейтами, кучей бюрократии (в статье об этом не говорится - а зря) и подковерных интриг, зачастую непрозрачными процессами (хотя снаружи банки кажутся весьма солидными организациями) - и пресловутым отсутствием профессионального роста. Называть в качестве причины ухода оплату труда - это наиболее цифровой (а потому наименее личностный) вариант - намного проще, чем объяснять настоящие причины.
В итоге реальная ситуация может намного сложнее и запутаннее, чем показывает опрос.
Поэтому если у программы будет "выхлоп" - респект вам, коллеги. Если нет - уверен, в процессе все участники получат интересный опыт :)
Кстати, есть небольшой вопрос автору - в KPI функциональных руководителей учитывается текучка подчиненных?
В то же самое время годовая инфляция в Еврозоне составила примерно те же 8.6% (https://ec.europa.eu/eurostat/documents/2995521/14644614/2-01072022-AP-EN.pdf) и впервые за долгое время евро торговался в паритете к доллару. Великобритания - около 9.4 (https://www.ons.gov.uk/economy/inflationandpriceindices/bulletins/consumerpriceinflation/latest). На все это с буддистcким (ну, или конфуцианским) спокойствием смотрит Китай со своими 2.5% (http://www.stats.gov.cn/tjsj/sjjd/202207/t20220709_1886257.html). Но китайские финансовые инструменты доступны в основном правильным китайским финансистам :)
Что же тогда делать простому индивидуальному инвестору в эти смутные времена? Складировать облигации госзаймов, которые всегда считались "тихой гаванью" или купить "на все" индексных фондов с максимальным региональным охватом, вцепиться в них как клещ и ждать, ждать, ждать...?
Автор довольно скептически относится к этой идее )
https://learning-python.com/python-changes-2014-plus.html#types35
Если не секрет, как удалось провезти его в страну?
Сам Amazon в РФ/РБ не доставляет. Заказал через посредника - теперь не могу вывезти его из Штатов (DHL не возит в РФ/РБ, USPS и AirMail не хотят связываться с перевозкой в самолете устройства с Li-Ion батареей). Уже убил на доставку ровно стоимость самого планшета - а "воз" и ныне "там" :(
Отличный текст, спасибо. Жду следующую статью :)
PS Правильно ли я понимаю, что для каждого пользователя фактически создается его личный кабинет с возможностью просмотра его собственных фотографий? Если да, то не планируется (если вообще это возможно) ли сделать там интеграцию с соцсетями? Навроде сценария: "Ух, какой классный кадр! Бахну как я его себе в <тут_некая_соцсеть>"