Как стать автором
Обновить
1
0
Алексей @vitesse

Пользователь

Отправить сообщение

В статье написано "Поскольку у нас нет цифровой подписи появится предупреждение" и если вы скачали расширение без подписи и установили себе, а потом подтвердили запуск с "возможным нарушением безопасности", то "вирусописатели говорят большое спасибо" вам.
Microsoft не может заблокировать полностью запуск без подписи - тестировать же нужно как-то расширения, да и для личных нужд можно без подписи (мы когда делали код для автоматического заполнения таблиц по XML-datasource, сделали расширение чтоб выводить все биндинги в виде tooltip для помощи себе в отладке).

Я брал в скобки слово "домашний" так как имел ввиду натуральность (в контексте статьи - "отечественность") и цепочку ингридиентов. Большинство любых проблем можно решить, просто затратив на это много ресурсов (время, деньги, силы). Экономическая целесообразность.

Честно, я как украинец, наверное должен был бы тоже написать ироничный комментарий, но напишу серьёзный. Если одним из главных достоинств продукта ставится его происхождение, то вам стоит пересмотреть приоритеты, сделайте акцент на удобстве (тот же Aspose это боль, так как разные API используют разные контракты, нумерацию страниц то с 0, то с 1, и т.д., но лучше чем некоторые аналоги), скорости (снова таки Aspose течёт по памяти), поддержке различных особенностей разных форматов документов (вот тут Aspose сравнительно хорош), поддержка (вот тут, вероятно происхождение может быть плюсом, так как проще вести диалог, но он как по мне слишком незначительный), скорость закрытия багов, документация (качество и отставание от реальности). Вот если по разным критериям, ваш продукт "догонит" или "перегонит" конкурентов, им будут пользоваться. Ну или если пока "не догоняет", то напишите, что вам нужна помощь в поддержке отечественной компании. Проблема современного мира в том, что мы сильно зависим от других людей и стран в том числе, и ограждаться от всех бесполезно - это как делать "домашний" майонез, колбасу или ещё что-то из покупных продуктов, телефоны и прочую электронику из китайских деталей. Не нужно делать культ из того, кем что-то сделано, лучше сфокусироваться на реальных достоинствах продукта - майонез вкуснее и без добавок, телефон быстрее и меньше разряжается и т.д.

А я бы добавил - соблюдайте одинаковый порядок кнопок во всем приложении/системе. Не как в Windows, то Печать/Отмена, то Ок/Справка, то Отмена/Ок, а то Да/Нет и главная кнопка, то слева, то справа. Я понимаю, что делали разные люди в разное время, но неужели так сложно это исправить... Примеров, к сожалению, не смогу привести с телефона.

Я вообще честно оптимист, но даже находясь в стационарном помещении меня и некоторых моих знакомых бывает от VR укачивает, а тут движущаяся машина... Нет, может ауди так плавно едет, поворачивает и тормозит, что пассажир ничего не почувствует. В общем, даже будучи оптимистом, я бы не разрешил пассажирам (а у меня это дети) на заднем сиденье играть VR по дороге в новенькой ауди. Мне кажется, хороший промышленный дизайн - это когда удобно и органично, а эта подборка о дизайне ради дизайна.

Спасибо за статью, было очень интересно почитать, вы очень подробно описали проект. Конечно у каждого проекта свои потребности, но ваши подходы и решения могут быть полезны начинающим архитекторам. Я бы даже сказал, что ваша статья лучше некоторых лекций и курсов, с которыми я сталкивался.

Заметил, что часто в коде над которым работают несколько разработчиков, возникает разница в порядке слов, например, mainDocument и documentMain в разных местах. В обоих случаях можно найти свои за и против, и единого стиля в итоге на проекте нет.
За статью спасибо, полезно бывает задуматься о таких базовых вещах.
Заранее прошу прощения, если кого-то обижу. Но что-то в новых иконках есть от Радужного флага (ЛГБТ) — такое же пёстрое и непонятное.

Прошу прощения за полёт мысли, но статья кажется слишком фантастичной. Общие авто существуют и сегодня, они дешевле чем покупать себе собственную машину того же качества, но особой популярностью они не пользуются, как писали выше — очередная ниша около такси. Свой автомобиль может и дорого, но это как своя квартира и общежитие, в своём автомобиле мне уютно, а садясь в такси — я чувствую, что это чужая территория. Пока общество построенно на потреблении, производители стремятся поддерживать принцип — владеть чем-то это круто. Поэтому тезис про общие беспилотные авто считаю утопией. Про голос и мысли — красиво, но я с "Ок, Гугл" максимум погоду могу проверить и будильник поставить, в остальном проще пальцами. А мыслями можно так "Создать письмо начальнику. Готово. И, что писать этому старому козлу? Что-то нужно отправить? Готово, ваше письмо отправлено! Ааааа!!!".

А тут очень интересный вопрос, что вы подразумеваете под словом «эффективность»? Больше фич, лучше качество, меньше стресса, больше доход… Одновременно всё? Я, проработав в куче проектов по разным методологиям как разработчик, ни разу не видел эффективности всего. Бывает за счёт снижения качества и увеличения стресса поднимают показатели количества фич (количество попугаев за спринт). Иногда наоборот, приходит новый менеджер и начинает заботится о качестве, в итоге меньше багов, больше тестов, меньше инцидентов, но вот только фич тоже меньше. А бывает, что не все фичи реально нужны, и просто возрастает процент бесполезных фич. Или тот же «кнут и пряник» — всё будет замечательно, кроме постоянного поиска и обучения новых сотрудников. Очень часто и разработчики, и те кто ими управляют всего лишь наёмные сотрудники для которых методологии это просто «бурление» чтоб показать свою «важность». Да и вообще, методологии сами по себе можно по разному применять. Я это всё к тому, что реальное влияние на доходы (текущие и особенно будущие) сложно коррелировать с методологиями разработки, они несомненно нужны, но должны подбираться под конкретный проект и сложность этого экспоненциально растёт с ростом компании.

P.S. Извините, что много текста — наболело.
Согласен с lair, но добавил бы ещё, что можно использовать разные типы exceptions (как стандартные, так и свои) для разных мест в коде, чтоб потом «ориентироваться откуда оно появилось». И вообще решение автора смотрится достаточно громоздко, запутанно, в команде из нескольких человек — будет вызывать конфликты.
Возможно вы и правы, вам виднее, но мне просто понравилось почитать красивую выдумку, заставляющую читателя побыть в роли Коли, Феди, Иры… Как-то вспомнилась что-ли молодость, учёба. Почти 13 лет прошло, многое кануло в лета, и забылось, а тут вот автор мне напомнил, что кроме семьи и работы у меня была другая жизнь. Преподаватели разные были — мудрые, умные, «добрые», строгие и глупые, и соответственно экзамены по знаниям, по шпорам, с бомбами и с пересдачами… а раз я даже за другого студента другого курса устно сдавал и сдал. Сейчас, мне кажется для моей текущей жизни, условий, бизнеса и семьи, большую пользу дали эти навыки «выживания» на экзаменах, ты учишься изворачиваться, и находить выход из тупиковых ситуаций, искать альтернативы, использовать знания, те что есть, по полной, и не сдаваться на пересдачах (да уж, тогда это казалось проблемами).
Интересный в каком-то смысле материал, можно ещё Roslyn подключить и анализировать код сборок, но полезность сомнительная. Извините, я спрашиваю из любопытства, а зачем вообще засовывать сборки в базу и ещё в таком количестве, чтоб потом специальным образом их искать и просматривать? На ум приходит некая система плагинов для клиентского приложения.
Как программист работавший в разных компаниях разрабатывающих проприетарное ПО, скажу, что не всегда тесты пишутся действительно качественно, случается, что они пишутся «чтоб было». А как писали выше, у заказчика вряд ли будут специалисты, средства и время на то, чтоб провести анализ этих тестов (учитывая, что тесты могут использовать какие-то фреймворки, запутанные патерны, инициализации и т.д. и т.п.). Есть компании, например, медицинские, которые сами пишут приёмочные тесты, и не примут релиз пока каждый тест не пройдёт — им это критично, они готовы за это платить. А если для бизнеса поломка продукта не критична, то выбирая продукт бизнес будет ориентироваться на известность, количество существующих клиентов, функционал и цену, а уже потом на наличие тестов. Машины, самолёты, оружие, медицинское оборудование — открыто тестируется просто потому, что их выход из строя очень критичен.
Так как интуитивно мне тоже казалось, что строки «abc» и «aaa» равнозначны и верить автору никак не хотелось, то я написал свой вариант проверки на C# dotnetfiddle.net/Ice8sV (желательно запускать с большим количеством итераций на локальном компьютере). Прогонял несколько раз и практически всегда стока «abc» собирается чаще чем «aaa» — с теор.вером. сложно спорить. Спасибо автору за интересную головоломку!

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Дата рождения
Зарегистрирован
Активность

Специализация

Backend Developer
Lead
C#
.NET Core
Microsoft SQL Server
ASP.Net
.NET
SQL
Git
Docker
Kubernetes
RabbitMQ