SharpDevelop, конечно, отличная среда разработки. Она несравнимо лучше чем MonoDevelop, так что как замена, конечно подошла бы. Но вот как на linux-системах дела с реализованными версиями .NET Framework? Я понимаю, что это вопрос не к IDE, просто лично мне трудно представить человека, который поставит SharpDevelop, скажем, при неполностью реализованном .NET Fw 3, когда сам активно использует возможности 4го…
Я заказал 9 (девять) наименований книг, поэтому доставка несколько полегчала. Это был первый заказ из-за бугра, но очень уж хотелось кое-что в оригинале и поскорее. Плюс терпеть не могу читать книги с экрана. А так да, переплата, конечно. Благо сейчас могу себе позволить.
К сожалению, мне не было так смешно. Оценить «промасленность» упаковки можете сами:
У книжек пострадали уголки, но я сраться не стал. Мне важнее содержимое книг в данном случае. Но в Амазон о проблеме всё равно отписал. Там тоже странные люди. Заявили, что упаковка «проверена» временем. На что я им сказал, что мне как бы пофиг про время проверки и всё такое. По факту товар повреждён, так что в след. раз давайте в водонепроницаемое тоже пакуйте. Они ответили, что подумают.
Интересно было бы ознакомиться с конкретным перечнем проведённых мероприятий по модернизации. Ну и о том по каким критериям Почта России «переплюнула» остальных претендентов на премию. :)
p.s. Месяц назад сделал заказ на амазоне. Три посылки доставлены очень быстро. Но одна была в масле. :)
Вот на этот вопрос не отвечу. Просто не пробовал. Может вводить было бы уже не так неудобно. Но вопрос переключения раскладки практически не снять.
В самой дискуссии по теме я бы хотел услышать от людей больше стоящих аргументов. Всё-таки способ ввода важен, но, возможно, не приоритетен.
А разве это не так? Локализация, схема обработки ошибок, безопасность (список может быть неполным) обязательно должны закладываться сразу и в любом проекте.
А я не писал, что вы категоричны в своём утверждении. И тем не менее, вы не ответили на мой вопрос. Кто-то из ваших знакомых говорил, что в частности из-за «приятности» английских слов пишет код на английском?
Пока что аргумент выглядит надуманным. Намного более надуманным, чем такое мнение, например: «Некоторые из программистов-новичков пишут код на английском, потому что такова традиция.»
Когда писал диплом, было много формул, что называется «из книжки». Применял греческий алфавит. Активнее всего использовались символы δ и φ. И вы знаете, набор был очень неудобен — приходилось «копипастить». А вот ожидаемого прироста читабельности кода я не заметил, так что мой подход оказался ошибочным.
Мой пример, конечно, неточно подпадает под ситуацию «все основные идентификаторы пишем кириллицей», но для кого-то может и будет аргументом в пользу традиционного подхода к именованию.
Не надо примешивать сюда моду, пожалуйста. С чего вы взяли, что сколько-нибудь значимая доля кодировщиков/программистов/разработчиков пишет код на английском по той причине, которую вы описали?
Одно дело писать код и другое дело именовать продукт. Если же говорить о брэндах, то я с вами согласен.
Если тема не сильно заезжена, расскажите, пожалуйста, о разнице в реализациях примесей в статически и динамически типизированных языках. Я могу ошибаться, но в C# 3.0 очень популярно использовать для этих целей методы-расширения. Поправьте, если не так. Меня больше всего интересуют примеси именно в статически типизированных языках: много ли реализаций, в чём их особенности и т. д.
Спасибо за хорошую статью!
Offtop
В серьезном, не учебном проекте следует использовать только ту технику, которая вам наиболее знакома и привычна в профессиональном плане (или ту, которая наиболее знакома и привычна большинству программистов, которые в будущем будут работать над проектом)
Эх, как же хочется, чтобы побольше людей так считало. Разумеется, это касается не только mixin'ов.
Да, я тоже подумал о том, что тяжело будет отделить дополнительную информацию от избыточной. А засорение мозга это нехорошо.
Как вариант, эту проблему можно решить возможностью очень быстрого (в один клик) отключения такой системы. Единственное толковое оправдание по тексту в ролике это связь между основным сервисом/частью реального мира и вот такими «информаторами».
С другой стороны, мне, если что-то требуется, достаточно открыть новую вкладку браузера с поисковиком. Это я к тому, что практическая ценность показанных информационных плюшек мне не ясна.
Я могу сильно ошибаться, но мне кажется, что понятие «эффективности» (и её повышение) несколько абстрактно. Каждый оценивает его с учётом своей собственной ситуации. Экономическая эффективность может достигаться разными способами. Кто-то будет пытаться экономить на фонде оплаты труда, а кто-то пойдёт иным путём.
В нашей компании IT-проекты не являются первичным направлением деятельности. Все кроме одного человека работают не в регионах/филиалах, а в Москве. В регионе — только дизайнер, которого приходится пинать для получения результатов в срок. У нас тоже деньги считают очень внимательно. Просто в нашем случае выгодно быстрее работать, чем экономить на зарплатах. Надеюсь, вы понимаете, что при прочих равных условиях, работа небольшой команды в пределах одного офиса осуществляется быстрее, чем удалённо. Я говорю о командах численностью 2-20 человек. Про более крупные коллективы не знаю.
Всё, что я хотел сказать, это то, что описанное вами решение не есть серебряная пуля. И следует несколько раз подумать, прежде чем решаться устраивать распределённую организацию.
А можно столь же подробно узнать о недостатках «распределённой организации»? Чем приходится платить за перечисленные выгоды?
У нас на проекте всего 2 из 10 человек работали удалённо, и то мы испытывали ряд проблем. В результате сейчас только с одним человеком работаем в таком режиме.
Спасибо за хорошее замечание про «капризы». Не написал об этом потому двум причинам. Во-первых, элементарно не вспомнил :). Во-вторых, у нас, когда коллеги составляют требования, мне как программисту очень тяжело что-то в них изменить (таков уж проект). Максимум, что я могу это: а) задать ряд «философских» вопросов, отвечая на которые автор изменений либо утвердиться в необходимости, либо поставит под сомнение нужность правок; б) объяснить цену внесения этих изменений авторам и руководству, а они уж решат, стоит ли овчинка выделки. Но в целом я стараюсь придерживаться лозунга, что «заказчику виднее».
Навскидку, средний размер ошибки составляет 30-150% времени. Но бывает и больше, конечно.
Особо не имею статистики по этому показателю, потому что часто несколько задач делаются почти параллельно. Выделить затраченное на каждую задачу время тяжеловато.
В разных местах были разные причины срыва. Были случаи, когда я как исполнитель (разработчик) не успевал что-то сделать из-за низких навыков, например.
Иногда таки менеджер ошибался со сроками не посовещавшись с программистами.
На настоящем же проекте мы постоянно не успеваем из-за того, что в тот момент, когда проектный договор подписывался, никто толком его не проверил. В результате имеем тучу работы, (за)критически мало трудовых ресурсов и очень «хорошие» сроки. Это нехороший пример «русского бизнеса». Оценку сроков якобы проводил сам заказчик. На момент подписания договора у нас в конторе был только один программист и тот слабенький (оценить риски неисполнения договора он бы не смог). А ещё одного специалиста и меня взяли примерно через 2,5 и 5 месяцев после запуска. Пока расхлябываем не так плохо, как я думал. И я не устаю повторять менеджеру про сроки и потребность в рабочих руках.
У книжек пострадали уголки, но я сраться не стал. Мне важнее содержимое книг в данном случае. Но в Амазон о проблеме всё равно отписал. Там тоже странные люди. Заявили, что упаковка «проверена» временем. На что я им сказал, что мне как бы пофиг про время проверки и всё такое. По факту товар повреждён, так что в след. раз давайте в водонепроницаемое тоже пакуйте. Они ответили, что подумают.
p.s. Месяц назад сделал заказ на амазоне. Три посылки доставлены очень быстро. Но одна была в масле. :)
В самой дискуссии по теме я бы хотел услышать от людей больше стоящих аргументов. Всё-таки способ ввода важен, но, возможно, не приоритетен.
Пока что аргумент выглядит надуманным. Намного более надуманным, чем такое мнение, например: «Некоторые из программистов-новичков пишут код на английском, потому что такова традиция.»
Мой пример, конечно, неточно подпадает под ситуацию «все основные идентификаторы пишем кириллицей», но для кого-то может и будет аргументом в пользу традиционного подхода к именованию.
Одно дело писать код и другое дело именовать продукт. Если же говорить о брэндах, то я с вами согласен.
Спасибо за хорошую статью!
OfftopЭх, как же хочется, чтобы побольше людей так считало. Разумеется, это касается не только mixin'ов.
Как вариант, эту проблему можно решить возможностью очень быстрого (в один клик) отключения такой системы. Единственное толковое оправдание по тексту в ролике это связь между основным сервисом/частью реального мира и вот такими «информаторами».
С другой стороны, мне, если что-то требуется, достаточно открыть новую вкладку браузера с поисковиком. Это я к тому, что практическая ценность показанных информационных плюшек мне не ясна.
В нашей компании IT-проекты не являются первичным направлением деятельности. Все кроме одного человека работают не в регионах/филиалах, а в Москве. В регионе — только дизайнер, которого приходится пинать для получения результатов в срок. У нас тоже деньги считают очень внимательно. Просто в нашем случае выгодно быстрее работать, чем экономить на зарплатах. Надеюсь, вы понимаете, что при прочих равных условиях, работа небольшой команды в пределах одного офиса осуществляется быстрее, чем удалённо. Я говорю о командах численностью 2-20 человек. Про более крупные коллективы не знаю.
Всё, что я хотел сказать, это то, что описанное вами решение не есть серебряная пуля. И следует несколько раз подумать, прежде чем решаться устраивать распределённую организацию.
У нас на проекте всего 2 из 10 человек работали удалённо, и то мы испытывали ряд проблем. В результате сейчас только с одним человеком работаем в таком режиме.
Особо не имею статистики по этому показателю, потому что часто несколько задач делаются почти параллельно. Выделить затраченное на каждую задачу время тяжеловато.
Иногда таки менеджер ошибался со сроками не посовещавшись с программистами.
На настоящем же проекте мы постоянно не успеваем из-за того, что в тот момент, когда проектный договор подписывался, никто толком его не проверил. В результате имеем тучу работы, (за)критически мало трудовых ресурсов и очень «хорошие» сроки. Это нехороший пример «русского бизнеса». Оценку сроков якобы проводил сам заказчик. На момент подписания договора у нас в конторе был только один программист и тот слабенький (оценить риски неисполнения договора он бы не смог). А ещё одного специалиста и меня взяли примерно через 2,5 и 5 месяцев после запуска. Пока расхлябываем не так плохо, как я думал. И я не устаю повторять менеджеру про сроки и потребность в рабочих руках.