Да она и в обычном немецком уже deprecated… Почти везде сейчас используется ss вместо эсцет. Так что совет искать эсцет скорее актуален, если перед вами текст из XX века.
Возможно и ошибаюсь в деталях, но в любом случае архиваторы распаковывают без проблем, в том числе и опенсорсные… А значит, при желании найти исходники для распаковки не такая уж и проблема.
Ну а .cab — это чаще всего тоже самое, что и zip deflate, в плане компрессии. Понятно, что там внутри куча мета-информации, как и в .docx или .odt. Но вопрос не в этом, а в том, сможет ли этот сервис конвертнуть .msi в .zip, если это такой редкий .msi, который нельзя «конвертнуть» в .zip тупо сменив расширение у файла?
Я бы даже уточнил, что это не просто риск, это факт, если проект не совсем уж тривиальный. После «водопада» результат получается почти всегда как в карикатуре про качели на дереве.
Это просто смена рода деятельности. Нельзя одновременно быть программистом и руководить серьезным бизнесом. Хотя может у некоторых людей с раздвоением личности и получится :-)
Другими словами, программист может стать руководителем, но в этом момент он либо перестанет быть программистом, либо станет фиговым руководителем.
Мне показалось, что статья скорее про Waterfall vs Agile, чем про американских и русских дизайнеров.
И в этом плане ничего нового: в случае водопада вы получаете фиксированный бюджет на 100 страничное ТЗ, который будет с достоверной вероятностью нарушен. С достоверной, потому что он будет превышен если вам хоть капельку не понравится то, что вам покажут в качестве первого результата работы. А во втором случае вы можете узнать только бюджет на итерацию, т.к. о бюджете и о ТЗ на весь проект agile-компания даже разговаривать не будет, потому что аппетит у заказчика меняется с каждой итерацией и хз сколько итераций займёт проект.
Для проекта, конечно, итеративная модель разработки лучше, если он не совсем уж тривиальный и при условии, что заказчик лучше понимает свою ЦА, чем исполнитель. Но почему-то многие заказчики с неохотой на неё соглашаются, им приятнее тешить себя иллюзией, что кто-то может точно оценить бюджет и сроки проекта в самом начале.
Блин, ну если кто-то считает, что в windows есть нормальная история команд, то пусть почитает хотя бы обзорную статью о возможностях нормальной истории команд, при том, что это только «верхушка айсберга».
Думаю, если Вы напишете подобную статью, как всё это сделать не в bash, а в cmd, получите кучу плюсов в карму :-)
Только не нужно, please…
«Individuals and interactions over processes and tools» © agilemanifesto.org
А в начале статьи говорили, что это фуфло… :-)
Другими словами, программист может стать руководителем, но в этом момент он либо перестанет быть программистом, либо станет фиговым руководителем.
И в этом плане ничего нового: в случае водопада вы получаете фиксированный бюджет на 100 страничное ТЗ, который будет с достоверной вероятностью нарушен. С достоверной, потому что он будет превышен если вам хоть капельку не понравится то, что вам покажут в качестве первого результата работы. А во втором случае вы можете узнать только бюджет на итерацию, т.к. о бюджете и о ТЗ на весь проект agile-компания даже разговаривать не будет, потому что аппетит у заказчика меняется с каждой итерацией и хз сколько итераций займёт проект.
Для проекта, конечно, итеративная модель разработки лучше, если он не совсем уж тривиальный и при условии, что заказчик лучше понимает свою ЦА, чем исполнитель. Но почему-то многие заказчики с неохотой на неё соглашаются, им приятнее тешить себя иллюзией, что кто-то может точно оценить бюджет и сроки проекта в самом начале.
Думаю, если Вы напишете подобную статью, как всё это сделать не в bash, а в cmd, получите кучу плюсов в карму :-)