cross_join — Отчасти согласен и про представления и про изучение. Но предприниматель реально может перекомпоновать на ходу свой бизнес и это повлечет сильно изменение. Предприниматель действует по факту на угад (риск на основе по прогнозов маркетологов) и он перестраивается под рынок и меняет требования. По этому ключевой фишкой scrum является не методология, а скидывание ответственности на product owner. А этот самый Owner — это не PM из команды (актер играющий роль), а реальный заказчик (мотивация другая).
Если разрабатываем компонент для ракеты, которую 3 года проектировал НИИ — там конечно другое дело, можно говорить, кто кто-то что-то недопонял и накосячил. Тут и водападить не грех.
Очень интересно почитать. Просто, Клево!
Хочу продолжение про то как организовывали свои службы и поставку запчастей. Каковы были при этом расходы в сравнении с расходами на подрядчиков (оутсерсеров, будь они… ).
Если, допустим, вы немец, то вы очень переживаете за прайвиси (частную жизнь), а ваш канцлер Меркель обязана по закону обеспечивать соблюдение конфиденциальности ваших персональных данных. Немецкий рабочий с гордостью заявляет мне, что номер его телефона не знает его руководитель. И нечего ему (руководителю) совать нос в его частную жизнь. А тут вся переписка непонятно у кого в руках.
Наш 152-фз не с потолка взят — это требование тех же самых немцев и американцев. Чисто технически я проблем не вижу. Какое техническое счастье дает миру сервер в США?
ну как бы элементарно отключить связь на кануне заварушки типи грузии в 2008 (когда кстати GPS врало нещадно самым неожиданным образом) и система поставок транспортными кампаниями по всей стране может быть сорвана, включая и военные поставки- мы все в одной лодке, а руль получается подвержен внешнему влиянию.
Ну а про то что призма используется для раскрытия коммерческих секретов и ее данные используется американскими компаниями первым далеко не Сноуден рассказал. А как по вашему эта призма работает? А это уже всех касается кто делает что по серьезней веб-сайтов.
А про то что тут писали что у нас большая часть компонентной базы импортная — фигня. Железки без ПО делится секретами не будут. К том уже, свои процы у нас пока еще есть (правда физически их вроде в поднебесной шлепают), а чьи резисторы или кондюки стоят — я думаю не так важно.
Я думаю потому что есть основание полагать, что те кто за занавесом не очень мягкие и своем не пушистые. Связь на сегодняшний день — сфера стратегически значимая для страны, причем не менее значимая чем ядерное оружие. А если вспомнить об «Военным и спецслужбам разрешат звонить по России напрямую» то шаг вполне логичный.
Я думаю если связистам дадут «выработать ресурс» имеющегося оборудования в разумных пределах и найдут способы стимулирования разработки отечественного железа (например показатели скорости и надежности работы принимать во внимание при оценке аналогов, а не только функционал ), то есть шансы чтобы «не получилось как всегда»
Предложение про группу с вашей подачи нашел. Я думаю продуктивнее для Максим Ксензова было бы изложить свою позицию и предложения сообществу в виде статьи и тем самым задать желаемый тон дискуссии. Вопросы с созданием топика при низкой карме, я думаю, возможно было бы решить с администрацией. Ведь случай исключительный.
Рассказ о винтиках государственной машины понятен. Можно посочувствовать им. Но в данном случае я не вижу попытки наладить диалог со стороны Максима Ксензова. Может не там ищу? Его комментарии еще больше распаляют хаброобщественность. Зачем он выступил на это площадке?
Вопрос к специалистам по TDD.
Регулярно читаю о том какой TDD хороший, и мучаюсь от такого. что никак не могу его применить. Я разработчик SMS-шлюза. Типичная messaging система: принял сообщения от внешней системы, чего-нить с ним поделал, отправил дальше и так во все стороны. Основная часть работы системы это: сетевой обмен, отправить/получить из БД (или очереди), переформатировать, маршрутизация. Естественно, при этом возникает куча процессов.
Ну вот никак не понимаю как тут применять TDD. Почитал wiki получается, что многопроцессные messaging системы — это сплошные слабые места для TDD:
* сетевой обмен
* БД
* межпроцессное взаимодействие
Привлекает в TDD то, что внеся любые изменения (а их вносить приходится много и постоянно), можно вжих-х-х — прогнать тесты и найти проблемы.
Подскажите куда капать, чего почитать? Или это не лечится?
Конвертер для даты в данном случае пишется в одну строчку, да и без конвертера можно прекрасно обойтись, если в календарике у первого числа каждого месяца вписать целое соответствующее число — проблемы нет никакой и повода городить огород с не очевидными правилами и писать статьи — отпадает сам собой. Сколько вы на это все времени убили? Вот всегда говорил — все проблемы от того что вещи используются не по назначению.
А вариантов для упрощения и тут много — зарезервировать под каждый год 500 дней под каждый месяц 40 — тогда двумя простыми делениями любую дату на ходу в голове преобразуете.
я уж не буду дискутировать на тему: «что есть файл и что есть БД и зачем нам индексированные выборки и возможность update». Просто разница между 3 картинкой и последней — ну очень большая.
Здесь задача — передать SMS для отправки на нужный сервис. — «к пуговицам претензий нет» (А. Райкин)
Если разрабатываем компонент для ракеты, которую 3 года проектировал НИИ — там конечно другое дело, можно говорить, кто кто-то что-то недопонял и накосячил. Тут и водападить не грех.
Хочу продолжение про то как организовывали свои службы и поставку запчастей. Каковы были при этом расходы в сравнении с расходами на подрядчиков (оутсерсеров, будь они… ).
Наш 152-фз не с потолка взят — это требование тех же самых немцев и американцев. Чисто технически я проблем не вижу. Какое техническое счастье дает миру сервер в США?
Ну а про то что призма используется для раскрытия коммерческих секретов и ее данные используется американскими компаниями первым далеко не Сноуден рассказал. А как по вашему эта призма работает? А это уже всех касается кто делает что по серьезней веб-сайтов.
А про то что тут писали что у нас большая часть компонентной базы импортная — фигня. Железки без ПО делится секретами не будут. К том уже, свои процы у нас пока еще есть (правда физически их вроде в поднебесной шлепают), а чьи резисторы или кондюки стоят — я думаю не так важно.
Новый анекдот? Черный юмор?
Сотрудники СС и НКВД тоже закон исполняли.
Регулярно читаю о том какой TDD хороший, и мучаюсь от такого. что никак не могу его применить. Я разработчик SMS-шлюза. Типичная messaging система: принял сообщения от внешней системы, чего-нить с ним поделал, отправил дальше и так во все стороны. Основная часть работы системы это: сетевой обмен, отправить/получить из БД (или очереди), переформатировать, маршрутизация. Естественно, при этом возникает куча процессов.
Ну вот никак не понимаю как тут применять TDD. Почитал wiki получается, что многопроцессные messaging системы — это сплошные слабые места для TDD:
* сетевой обмен
* БД
* межпроцессное взаимодействие
Привлекает в TDD то, что внеся любые изменения (а их вносить приходится много и постоянно), можно вжих-х-х — прогнать тесты и найти проблемы.
Подскажите куда капать, чего почитать? Или это не лечится?
А вариантов для упрощения и тут много — зарезервировать под каждый год 500 дней под каждый месяц 40 — тогда двумя простыми делениями любую дату на ходу в голове преобразуете.
Здесь задача — передать SMS для отправки на нужный сервис. — «к пуговицам претензий нет» (А. Райкин)
Очень понравилась цитата в Вашем профиле.